Node-M Terminal Emulator for C128

Node-M is a custom terminal emulator program I created so I could work on my university Computer Information Science assignments from home over 2400 baud modem with my Commodore 128, about 30 years ago 1988-1989.  This article documents the solution, the ADM31 comparable emulation, and provides C128 disk image and UNIX/Linux support files (link to ZIP file).  Source file is included using The Fast Assembler (also source listing).

My favorite features were color, secondary composite graphics screen, full screen editing support (for me that was vi), full ASCII character set (backslash, backquote, caret, curly braces, vertical bar, underscore, tilde), keyboard support, printer support, and interlaced 80-column x 50-line mode (sorry not shown, doesn't work well in VICE).  Notable missing features are flow control and file transfer.

Keyboard changes for ASCII

• Commodore+Q is Left Brace {
• Commodore+W is Right Brace }
• Commodore+E is Tilde ~
• Commodore+R is Backquote `
• Commodore Minus is Vertical Bar |
• British Pound is Backslash \
• Up Arrow is Caret (Hat) ^
• Left Arrow is Underscore _

ADM31 terminal emulation, with additions/variations

• {Ctrl+?} 127 DEL
• {Ctrl+G} 7 BELL
• {Ctrl+H} 8 RIGHT
• {Ctrl+I} 9 TAB
• {Ctrl+J} 10 LINEFEED
• {Ctrl+K} 11 UP
• {Ctrl+L} 12 RIGHT
• {Ctrl+M} 13 CARRIAGE RETURN
• {Ctrl+W} 23 CLEAR TO END OF SCREEN
• {Ctrl+X} 24 CLEAR TO END OF LINE
• {Ctrl+^} 30 HOME
• {Ctrl+Z} 26 CLEAR SCREEN / HOME
• {Ctrl+[} 27 ESC
• ESC t CLEAR TO END OF LINE (ESC T)
• ESC y CLEAR TO END OF SCREEN (ESC Y)
• ESC : CLEAR SCREEN / HOME (ESC *)
• ESC ) HALF INTENSITY ON
• ESC ( HALF INTENSITY OFF
• ESC G 0 CLEAR ATTRIBUTES
• ESC G 1 ALTERNATE CHARACTER SET ATTRIBUTE
• ESC G 2 FLASH ATTRIBUTE
• ESC G 3 UNDERLINE ATTRIBUTE
• ESC G 4 REVERSE ATTRIBUTE
• ESC H 2 4 INIT SCREEN 24 LINES
• ESC H 5 0 INIT SCREEN 50 LINES
• ESC ESC ESC {32 TO 47} FOREGROUND SCREEN COLOR 0-15
  {space}black !dkgray “blue #ltblue $green %ltgreen &dkcyan 'cyan (red )ltred *dkpurple +purple \dkyellow -yellow ^medgray _white
• ESC ESC ESC {48 TO 63 or 96 TO 111} BACKGROUND CHARACTER COLOR 0-15
  0black 1dkgray 2blue 3ltblue 4green 5ltgreen 6dkcyan 7cyan 8red 9ltred ;dkpurple :purple <dkyellow =yellow >medgray ?white
  `-black a-dkgray b-blue c-ltblue d-green e-ltgreen f-dkcyan g-cyan h-red i-ltred j-dkpurple k-purple l-dkyellow m-yellow n-medgray o-white
• ESC = {32 TO 55/81} {32 TO 111} MOVE CURSOR TO ROW (0-23 or 0-49), COLUMN (0-79)
• ESC E INSERT LINE
• ESC Q INSERT CHARACTER
• ESC R DELETE LINE
• ESC W DELETE CHARACTER
• ESC L {64 TO 79} {64 TO 79} {64 TO 79} {64 TO 79} PIXEL POSITION XH XL YH YL (X=0 TO 319, Y=0 TO 199), SAVE OLD X,Y
• ESC M {EVEN/ODD} PIXEL COLOR (0=BACKGROUND, 1=FOREGROUND)
• ESC P PLOT AT PIXEL POSITION
• ESC D DRAW LINE BETWEEN OLD AND CURRENT PIXEL POSITION
• ESC C CLEAR GRAPHIC SCREEN
• ESC < SLOW, ENABLE GRAPHIC SCREEN
• ESC > FAST, DISABLE GRAPHIC SCREEN
• ESC F FILL AT PIXEL POSITION
• ESC B CLEAR GRAPHIC BLOCK (RECTANGLE DEFINED BY OLD AND CURRENT PIXEL POSITION)

Note: running the C128 in emulation I couldn't quite get the terminal to talk over TCP/IP serial emulation directly to my Linux telnet service, so I ran a shell script in between to do a conversion (from some hints on stack overflow):

#!/bin/sh
mkfifo temp

while true; do nc -l 127.0.0.1 23 < temp | dd bs=1 | nc -t 192.168.56.101 23 | dd bs=1 > temp ; done

40 column RGB screen for Commodore 64 mode on 128

RGB64 is a solution for a problem almost no one has -- use the C128 RGBI screen for C64 mode text programs and editing in 40 columns!  Now you can go back to using one monitor for both, and without using a hardware switch.  Well, as long as you're not using any graphics or pokes to video memory.   If you are editing or running a simple text BASIC program, you can use RGB64 to mirror your screen between both monitors.  As a bonus, you can run in fast mode 2MHz, because the RGBI screen runs independently from the VIC that could only access video memory at 1MHz.  Another bonus is that the extra keys of the C128 keyboard are supported as well.

Your Commodore 128 has an 80-column RGBI screen, and a 40-column Composite screen.  One of the original dual monitor systems!   So you probably prefer the RGBI screen for the C128 mode, and you're usually stuck using composite output (or worse, TV signal) for the C64 mode.  And that means you gotta have one or more monitors that support both.   Well not anymore!   You can now downscale your 80-column monitor to 40-columns for simple Commodore 64 programs.

How does it work?  It copies the C64 ROMs to RAM, and patches them to include routines to initialize and update the RGBI screen with a 40 column image matching the text output to the VIC screen.  It also copies the C64 character ROMs to 8563 VDC RAM.  Then switches to C64 mode.  No going back until you press the Reset switch.

So maybe you didn't know the 8563 VDC could do 40 columns, because hey, it was included in the Commodore 128 to do 80 columns.  Well, you know it can do graphics, and interlaced modes for higher resolutions.  Did you know it can do 50 lines of text?  Did you know it can do 8x16 pixel characters as well?  In addition to all that, it can also double the width of the pixels, so presto, with a few more adjustments it can also do 40 columns instead of 80.

KEYBOARD SUPPORT

• HELP will copy the VIC Composite screen to the VDC RGBI screen (in case of pokes)
• ALT will toggle Fast mode (2MHz)
• C128 extended keys are supported including dedicated cursor keys and numeric keypad, even CAPS LOCK

WARNINGS (Sorry the lawyers in my head make me put these in)

• Warning!  This code has been tested solely on a NTSC C128D 8563 rev2, and with VICE 3.3.  PAL, rev0, and rev1 chips may not be supported.  I didn't even test with a true Commodore monitor, but a compatible (Thomson 4120 switchable RGBI/Luma+Chroma).
• Warning! I haven't tested on a real Commodore 128 since 1990 or so.  (But it's only 8 feet away from me, I guess I could plug it in again, but that requires effort.)
• Warning! And I will not be responsible if this program kills your monitor.  Gee I sure hope it doesn't.
• Warning! All the ROMs (BASIC and KERNAL) are now in RAM.  One wrong poke, and poof system locks up or worse.   Then again, it's a fun environment to hack the ROMs with.
• Warning! Uses $991C-$99D2 for RGB64 machine language component.
• Warning! RGB64 is probably not compatible with the other software you use.
• Recommend you try RGB64 in Vice (emulation).  Emulation should be easier on your monitor.  And if it doesn't work, those bits can simply be recycled into something else.

The reason I built this was that about 30 years ago my monitor was on the fritz, I sent it for repair, and had no good composite monitor.  I did have an amber monochrome monitor.  My development system relied on The Fast Assembler (Thanks Yves Han!) which ran in C64 mode, so only 40-column mode.  I had been using the 50 line mode of the VDC 8563 and in messing around with the settings, found the 40 column mode too.   Turned out the monitor had an extra circuit board with edge connector that came loose and only needed to be re-plugged into the main circuit board, so the need for this utility was short lived.  But I got a kick out of writing it, and wanted to share it.

The code is mostly original from about 30 years ago except for some updates today to carve my name in it  with URL.  Gotta take credit for the hard work, right?  

Where the magic happened -- my Computer Workstation

Links:
RGB64 Disk image (.D64), mount and type: RUN"RGB" from C128
Source Disk image (.D64) including The Fast Assembler plus ScrollEdit with RGB64 patches.
RGB64 Decompilation, Annotated (.PDF)
Hackaday posted a short article about this project!

C64: Scrolling Editor for The Fast Assembler, 31 years late

Starting just today you can write Commodore 64 assembly language programs compiled for 6502 with The Fast Assembler and scroll up and down through them with just a touch of a function key. No more need to rely solely on the LIST keyword.  This tool has been available for BASIC programmers for quite a while.  But now it is also available for 6502 assembly language programmers too.

Key	Description
F1	Scroll up
F3	Beginning of line
F5	End of line
F7	Scroll down
Ctrl+Down	Bottom of screen
Ctrl+Ins	Insert Line
Ctrl+Shift+Commodore	Renumber lines
Ctrl+Return	Toggle Scroll Edit Keys On/Off
Stop+Restore	Restore screen and program (unnew)

I wrote the scrolling extension for The Fast Assembler way back in the summer of 1987 and submitted it to Compute! magazine for publishing.  Yet only my Scrolling BASIC Editor for Commodore 64 was published in their magazine and distributed on their floppy disk.  No one had seen the extension version since and the code has been sitting dormant in storage for a long time.

Yves Han wrote The Fast Assembler and it was published in January 1986 Compute!'s Gazette.  When I went about to write the original Scrolling BASIC Editor, I used The Fast Assembler to write the source code and assemble into machine code.  I felt this was the perfect tool for writing machine language programs, so I proceeded to integrate it into his solution as well.

Also added to The Fast Assembler with this extension are low byte < and high byte > operators similar to one or more assemblers of the era.

Fast forward over 31 years to today when writing this article, and I've got the retro hardware bug and retrieved the data from some of my old Commodore floppy disks using ZoomFloppy.   Add in a dash of Commodore emulators, archived magazines and disks, blogs, and electronic mail, and we've got new interest, and new means of self publishing and distributing information.  And I just recently changed my credits to my website URL (no we did not have those prior to 1990), otherwise no logic was changed in the last many decades.

Thanks to Tiaan Geldenhuys I saw this great blog post about The Fast Assembler.  Also thanks to email I was able to contact Yves Han, the author of The Fast Assembler.

Below are some resources.  Recommend you grab the floppy disk images instead of typing in the programs from the magazines.  The integrated version is available ready to use as FA+SCRLEDIT.

If you want to recreate from source you can because all source is available.  And/or if you wish to create the patched integration from compiled versions, instructions can be listed from  README.BASIC.

These are links:
• SCRLEDIT extension for The Fast Assembler C64 Disk Image (FA+SCRLEDIT) [1987, 2019]
• Compute's Gazette January 1988 Scrolling BASIC Editor Article
• Compute's Gazette January 1988 Floppy Disk Image (SCROLLEDIT) [BASIC]
• Compute's Gazette January 1986 Floppy Disk Image (ASSEMBLER) [original]

eBible on Cortex M0 with mbed

The eBible code has been ported from to use a Cortex M0 device and external flash chip.  The original chip used an M3 with lots of flash and SRAM, but this M0 part (NXP LPC1114FN28) has only 32Kbytes flash and 4Kbytes SRAM.

The challenge was to reduce and rewrite the functionality using less resources.  The M3 solution had used an SD card with FAT filesystem and had access to 512Kbytes flash and 64Kbytes SRAM.  All that was originally required was the bible.txt file on the SD, and the firmware would index all the books, chapters, and verses for navigation into multiple files on the SD card the first time it ran.  The M3 had no problem loading large sections of the text into memory to parse it into verses.  The M0 with its limited resources has less capability.

The M0 version does not use a file system, so the Bible text and index data are stored sequentially in flash storage (Spansion S25FL164K).  The index data structure is a sequence of structures for books, then intermixed with structures for chapters and verses.  The structures include text offsets, counts, and variable sized arrays pointing to other structures.  A fixed offset to the index structure, and bookmark structure is included in the code.  A separate firmware program for the M3 was written to convert the SD text and indexes and store them in flash.  This program was run once on the M3 to populate the flash chip, then the flash chip was moved to the M0 circuit.

Two different SPI circuits are present with one for the display and one for the flash.  The M0 chip used only has one SPI peripheral, so software SPI (bit banged) was implemented (ported from my C# implementation) to simulate another SPI peripheral.

A Text LCD wrapper library targeting Nokia 5110 was written to reduce the number of changes to the eBible source in porting from a text only lcd to the graphical Nokia 5110 lcd.

The remaining portions of the circuit to mention are the 3.3V voltage regulator (Microchip MCP1702), Nokia 5110 LCD display (purchased on eBay from a seller in Shenzhen, China), two switches, three blue LEDs, three AAA batteries, a battery holder, and some sockets.  A surface mount prototyping adapter board (SO8-50-EB) was used to attach the flash memory.  Two screws secure the battery holder to the circuit board.  The outside LEDs mirror the button presses, and the center LED flashes when bookmarks are changed when holding down both buttons.  Pressing the left button goes back one screen of text, and the right button advances to the next screen of text or next verse whichever comes first.  Holding down the buttons for a time navigates back or forward by multiple verses, chapters, or books depending on how long they are held down.  While navigating large sections of text, the book name, chapter number, and verse number are displayed, then switch back to the text after the buttons are released.

The parts chosen were primarily with consideration of cost.  The memory, display, and microcontroller are mbed online compiler and mbed library.  For debugging, the code was simply exported from the online compiler to Keil uVision 4 using a SeeedStudio Arch to act as the CMSIS-DAP debugger and programmer.  Being able to use a full-featured IDE including debugger for an mbed target is greatly appreciated.  Most of the work was done with the components in a breadboard, then transferred to a solder prototyping breadboard.  The result is a handheld electronic Bible that is smaller and more cost efficient that the originally developed version.

Schematic

mbedR3uino: mbed adapter for Arduino shields

The mbedR3uino is a vertical shield adapter for the mbed prototyping platform.  It provides compatibility with standard Arduino shields including the pins added to Arduino Uno R3 to make shields more independent between main boards.

This is the project I wanted three years ago.  Finally the need, inspiration, materials, and dependent projects converged.  The ability to easily add pluggable hardware to the mbed had been demonstrated when I created the In-between Shield for mbed which plugged into the mbed workshop board adding flash memory to the mbed which plugged into the shield. 

 

I have developed a number of prototype shields for Arduino using a ProtoShield that have been compatible with my various Arduinos, Netduinos, and other development boards providing plug compatibility with Arduino shields.  With the addition of the new R3 pins: SCL, SDA, IOREF some more platform independence has occurred allowing the shield (or at least its I/O) to run at the same voltage as the target platform, and a standardization of the location of the I2C pins.  The SPI pins which were originally reserved for ICSP or initial programming of the Arduino also became a standard.  I opted to skip the SPI/ICSP pin compatibility and stick with the Uno SPI pin layout for simplicity; a future version should include the SPI/ICSP pins in their expected location.  An R3 version of the ProtoShield was found here and I had seeedstudio build the PCBs.

The mbedR3uino is named because mbeduino was already taken.  Inserting the R3 in the name gives it some uniqueness while expressing its meaning.  The adapter consists of two pluggable pieces.  The first plugs into the workshop board above the mbed providing a footprint identical to the mbed.  Components were added to the ProtoShield to plug it into the first piece, and wire the connections to the Arduino R3 headers.  The result is that Arduino shields can be connected to the mbed.

Standard height 0.45" header pins were used to connect the ProtoShield to the above mbed adapter.  The above mbed adapter used taller 0.7" header pins so the PCB barely clears the height of the mbed, only touching the mini USB socket.  Since my prototyping boards have solder terminals only on one side, and to keep them clean looking I try to solder only on the bottom, hidden from view, I used needle nose pliers to push the pins so the plastic is flush with the top of the pins, and then carefully solder the pins from the bottom of the board not getting them too hot or the pin could waver out of place.  Once all the pins are soldered into place they hold very securely.

Note that the mbed workshop board or equivalent is required.  It already provides SD, Ethernet, and USB connectivity.  I have a revA board which pin 9 is held high to 3.3V (intended for SD card detect?), so to allow it to be used for the UART, I cut the trace on the workshop board.  An alternative to using the workshop board would be to have dual row headers and connect the columns for all pins 1-40, as done in my mbed Text LCD development board.  It is relatively easy to also solder a USB B connector, and an Arduino shield can be used for an SD card.  Connecting an Ethernet jack directly to the mbed can be done using a breakout board.

All the available pins on the mbed are either connected to the Arduino headers, or a few are broken out for additional expansion: since the workshop board already uses pins 5-8, they were left as an expansion; CAN and battery lines are implemented as jumpers for expansion.  Analog pins and power pins are where they should be, one UART is wired to D0/D1 for Arduino compatibility, and one SPI is wired for original Uno compatibility (D13-D10).  One pair of I2C pins are in the new R3 location, and the same pins are also wired to the same location as done with the Leonardo: D2/D3.  The remaining D14 and PWM pins are wired to the remaining Arduino header pins.  The schematic below shows how I chose to map the pins between the boards.

Schematic - Click on image to view larger

3V-5V Switchable I2C Real Time Clock Shield

This is a prototyped Arduino shield that is 5V and 3V switchable.  The real time clock (RTC) is a DS1307 running at 5V, with a backup battery to keep time while not plugged into another power source.  It connects with an Arduino or similar board via I2C, but using a voltage translation (level shifter) circuit using FETs (reference: Philips) to isolate the RTC chip that always runs at 5V from the Arduino CPU which can be running at either 5V or 3V.  This provides support for 3V Arduino format boards such as the Arduino Due which can be damaged if 5V is applied to its lines.  Jumpers are provided to select the voltage (red), the I2C lines used (D3/D2 or A5/A4), and whether 3.3K pull-ups are used on the microcontroller side of the circuit.  Note the RTC always has its pull-ups in place.

Note that due to USPS regulations, Lithium batteries cannot (without meeting specific conditions) be shipped via US airmail so my Digi-Key order that included the FETs and crystal was revised to eliminate the batteries.  These are available cheap in bulk from many distributors, but to save immediate costs including shipping I ended up purchasing a single one at the local drug store.  Next time I may use ground shipping for such items, but I also found a local electronics supplier that has a decent price.

 

The DS3107 chip was purchased overseas via eBay as it was available much cheaper than domestically.  Hint: look for free shipping.

Schematic

A different 3V RTC chip could also be used, such as a surface mount chip, and then the level shifting circuit (FET drain/source) needs to be reversed per the original circuit recommended by Philips Semiconductors because the low/high sides of the circuit are reversed when the RTC is running at 3V and the microcontroller is running at 5V.

For prototyping the FETs ordered are in package TO92-3.  I ordered two different FETs and ended up using the more expensive ones with a higher Vdss rating (200V).  A cheaper FET in SOT-23 packaging with a lower rating of 50V was also sourced but not tested.

Adafruit has a tutorial including an Arduino library for use with the DS1307.  I tested this library on the Arduino Leonardo and Duemillanove running at 5V.  For the 3V Due, I used simple raw I2C (Wire library) commands to talk to the DS1307.  Only SCL1/SDA1 worked for me on the Due (had to jumper these as the ProtoShield is pre-R3 and doesn't have dedicated SCL/SDA pins).

(I had meant to publish this article in February but due to some bad soldering on my part and challenges with the Due, this prototype wasn't working properly.  Took multiple re-visits to fix everything.  Now I am very glad it is working now.)

Getting started with OpenOCD

As referenced in my JTAG Adapter post the OpenOCD project is an open source JTAG program and set of drivers.  Professional JTAG programmers can commonly cost US $100 and up (some are thousands), and are often proprietary to a specific development toolset.  Open source and open hardware efforts have made JTAG available at much lower cost and at least works with open source development toolsets such as gcc/gdb and Eclipse, as well as some commercial offerings that are built on Eclipse.

Olimex has collected these open source development toolsets with OpenOCD and created a single installer called Olimex OpenOCD Development Suite for use with their development boards and their JTAG programmer.   Installing their suite is one of the easiest ways to get an ARM gcc toolchain installed on your system with an IDE and JTAG programmer.  Their toolset includes OpenOCD, Eclipse, gcc/gdb, and Zylin Embedded CDT.  Sample projects are provided for some of their Atmel, STM32, and NXP (LPC) boards.  I found that I needed to perform slight revisions their OpenOCD scripts included in at least the SAM7-P256-cdc_FLASH project because they were out of date.  Once that was done, I was using my JTAG adapter with their ARM7 board performing programming and debugging.  This suite and examples can be leveraged to target other boards. 

OpenOCD can also be used directly from the command line to make a connection with a board, and then use telnet to issue commands (see User's Guide) to direct it.  From the command line you can verify and discover commands to issue to your board.  In the following examples I will use my JTAG programmer to talk to the STM32F4Discovery board.  I have a breakout board for this development board that includes a JTAG socket.  I have disconnected the jumpers on the STM32F4Discovery for its onboard ST-LINK/V2 debugger, so I can use my JTAG programmer instead.

First you must have an interface script to talk to your JTAG programmer.  From the openocd-0.6.1 directory, I copied scripts/interface/ftdi/flossjtag.cfg to the file ft2232h.cfg in the current directory.  Then I commented out the ftdi_device_desc statement in that file, and appended
    adapter_khz 500
to the end of the file.

$ bin/openocd-0.6.1.exe -f ft2232h.cfg -f scripts/target/stm32f4x.cfg

Open On-Chip Debugger 0.6.1 (2012-10-07-10:34)
Licensed under GNU GPL v2
For bug reports, read    http://openocd.sourceforge.net/doc/doxygen/bugs.html
WARNING!
This file was not tested with real interface, it is based on code in ft2232.c.
Please report your experience with this file to openocd-devel mailing list,
so it could be marked as working or fixed.
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints

Then I open a telnet window to localhost port 4444.  From here I can issue various commands to OpenOCD to perform JTAG commands.

$ telnet localhost 4444

Open On-Chip Debugger
> reset halt
JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
> flash probe 0
device id = 0x10016413
flash size = 1024kbytes
device id = 0x10016413
flash size = 1024kbytes
flash 'stm32f2x' found at 0x08000000
> flash banks
#0 : stm32f4x.flash (stm32f2x) at 0x08000000, size 0x00100000, buswidth 0, chipwidth 0
> flash list
{name stm32f2x base 134217728 size 1048576 bus_width 0 chip_width 0}
> flash erase_check 0
successfully checked erase state
        #  0: 0x00000000 (0x4000 16kB) erased
        #  1: 0x00004000 (0x4000 16kB) erased
        #  2: 0x00008000 (0x4000 16kB) erased
        #  3: 0x0000c000 (0x4000 16kB) erased
        #  4: 0x00010000 (0x10000 64kB) erased
        #  5: 0x00020000 (0x20000 128kB) erased
        #  6: 0x00040000 (0x20000 128kB) erased
        #  7: 0x00060000 (0x20000 128kB) erased
        #  8: 0x00080000 (0x20000 128kB) erased
        #  9: 0x000a0000 (0x20000 128kB) erased
        # 10: 0x000c0000 (0x20000 128kB) erased
        # 11: 0x000e0000 (0x20000 128kB) erased
> dump_image image.bin 0x08000000 0x100000
dumped 1048576 bytes in 14.406221s (71.080 KiB/s)
> flash write_image erase stm32f4discovery_00.s19
auto erase enabled
wrote 1048576 bytes from file stm32f4discovery_00.s19 in 31.499985s (32.508 KiB/s)
> reset run
JTAG tap: stm32f4x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
JTAG tap: stm32f4x.bs tap/device found: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
> exit


^C

There you have it, some example OpenOCD commands.  Hope you learned something useful.