- ROM Applications document has been consolidated into the Applications document
- Martin has done a significant overhaul of the Applications document
Co-Authored-By: MartinR <174514335+martinr-uk@users.noreply.github.com>
SVC | hl de bc n -- hl de bc af | Execute a ROMWBW function
P! | n p -- | Write a byte to a I/O port
P@ | p -- n | Read a byte from and I/O port
# BASIC
For those who are not familiar with BASIC, it stands for Beginners All purpose Symbolic
Instruction Code.
ROMWBW contains two versions of ROM BASIC, a full implementation and a "tiny" BASIC.
The full implementation is a version of Microsoft BASIC from the NASCOM Computer.
A comprehensive instruction manual is available in the Doc\\Contrib directory.
## ROMWBW specific features
- Sound
- Graphics
- Terminal Support
## ROMWBW unsupported features
- This ROM-hosted implementation does not support cassette or disk
access for loading and saving programs.
# TastyBASIC
TastyBASIC offers a minimal implementation of BASIC that is only 2304 bytes in size.
It originates from Li-Chen Wang's Palo Alto Tiny BASIC from around 1976. It's small size suited the tiny memory capacities of the time. This implementation is by Dimitri Theulings and his
original source can be found here [https://github.com/dimitrit/tastybasic](https://github.com/dimitrit/tastybasic)
## Features / Limitations
- This ROM-hosted implementation does not support disk access for
loading and saving programs.
- Integer arithmetic, numbers -32767 to 32767
- Singles letter variables A-Z
- 1-dimensional array support
- Strings are not supported
## Direct Commands
-`LIST`,`RUN`, `NEW`, `CLEAR`, `BYE`
## Statements
-`LET`, `IF`, `GOTO`, `GOSUB RETURN`, `REM`, `FOR TO NEXT STEP`, `INPUT`, `PRINT`, `POKE`, `END`
## Functions
-`PEEK`, `RND`, `ABS`, `USR`, `SIZE`
## Operators
-`>=`, `#`, `>`, `=`, `<=`, `<`
- Operator precedence is supported.
Type ***BYE*** to return to the monitor.
# Play a Game
## 2048
2048 is a puzzle game that can be both mindless and challenging. It
appears deceptively simple but failure can creep up on you suddenly.
It requires an ANSI/VT-100 compatible colour terminal to play.
2048 is like a sliding puzzle game except the puzzle tiles are
numbers instead of pictures. Instead of moving a single tile all
tiles are moved simultaneously in the same direction. Where two
tiles of the same number collide, they are reduced to one tile with
the combined value. After every move a new tile is added with
a starting value of 2.
The goal is to create a tile of 2048 before all tile locations are
occupied. Reaching the highest points score, which is the sum of all
the tiles is a secondary goal. The game will automatically end when
there are no more possible moves.
Play consists of entering a direction to move. Directions can be entered
using any of three different keyboard direction sets.
```
Direction | Keys
----------|----------
Up | w ^E 8
Down | s ^X 2
Left | a ^S 4
Right | d ^D 6
```
The puzzle board is a 4x4 grid. At start, the grid will be populated
with two 2 tiles. An example game sequence is shown below with new
Press Q at any time to bring up the option to Quit or Restart the game.
# Network Boot
# Xmodem Flash Updater
The ROMWBW Xmodem flash updater provides the capability to update ROMWBW from the boot loader using an x-modem file transfer. It offers similar capabilities to Will Sowerbutts FLASH4 utility except that the flashing process occurs during the file transfer.
These are the key differences between the two methods are:
Available from the boot loader | Well proven and tested
Xmodem transfer is integrated | Wider range of supported chips and hardware
Integrated checksum utilities | Wider range of supported platforms
Capability to copy a ROM image | Only reprograms sectors that have changed
More convenient one step process | Ability save and verify ROM images
No intermediate storage required | Progress display while flashing
. | Displays chip identification information
. | Faster file transfer
The major disadvantages of the Updater is that it is new and relatively untested. There is the risk that a failed transfer will result in a partially flashed and unbootable ROM. There are some limitations on serial transfer speeds.
The updater utility was initially intended to support the Retrobrew SBC-V2-005 platform using Atmel 39SF040 flash chips but has now been extended to be more generic in operation.
The Atmel 39SF040 chip is recommended as it can erase and write 4Kb sectors. Other chips require the whole chip to be erased.
## Usage
In most cases, completing a ROM update is a simple as:
1. Booting to the boot loader prompt
2. Selecting option X - Xmodem Flash Updater
3. Selecting option U - Update
4. Initiating an X-modem transfer of your ROM image on your console device
5. Selecting option R - Reboot
If your console device is not able to transfer a ROM image i.e. your console is a VDU then you will have to use the console options to identify which character-input/output device is to be used as the serial device for transfer.
When your console is the serial device used for the transfer, no progress information is displayed as this would disrupt the x-modem file transfer. If you use an alternate character-input/output devices as the serial device for the transfer then progress information will be displayed on the console device.
Due to different platform processor speeds, serials speeds and flow control capabilities the default console or serial device speed may need to be reduced for a successful transfer and flash to occur. The **Set Console Interface/Baud code** option at the Boot Loader can be used to change the speed if required. Additionally, the Updater has options to set to and revert from a recommended speed.
See the ROMWBW Applications guide for additional information on performing upgrades.
## Console Options
Option ( C ) - Set Console Device
Option ( S ) - Set Serial Device
By default the updater assumes that the current console is a serial device and that the ROM file to be flashed will also be transferred across this device, so the Console and Serial device are both the same.
Either device can be can be change to another character-input/output device but the updater will always expect to receive the x-modem transfer on the **Serial Device**
The advantage of transferring on a different device to the console is that progress information can be displayed during the transfer.
Option ( > ) - Set Recommended Baud Rate
Option ( < ) - Revert to Original Baud Rate
## Programming options
Option ( U ) - Begin Update
The will begin the update process. The updater will expect to start receiving
an x-modem file on the serial device unit.
X-modem sends the file in packets of 128 bytes. The updater will cache 32
packets which is 1 flash sector and then write that sector to the
flash device.
If using separate console, bank and sector progress information will shown
```
BANK 00 s00 s01 s02 s03 s04 s05 s06 s06 s07
BANK 01 s00 s01 s02 s03 s04 s05 s06 s06 s07
BANK 02 s00 s01 s02 s03 s04 s05 s06 s06 s07 etc
```
The x-modem file transfer protocol does not provide any filename or size
information for the transfer so the updater does not perform any checks
on the file suitability.
The updater expects the file size to be a multiple of 4 kilobytes and
will write all data received to the flash device. A system update
file (128kb .img) or complete ROM can be received and written (512kb or
1024kb .rom)
If the update fails it is recommended that you retry before rebooting or
exiting to the Boot loader as your machine may not be bootable.
Option ( D ) - Duplicate flash #1 to flash #2
This option will make a copy of flash #1 onto flash #2. The purpose of this is to enable
making a backup copy of the current flash. Intended for systems using 2x512Kb Flash devices.
Option ( V ) - Toggle Write Verify
By default each flash sector will be verified after being written. Slight
performance improvements can be gained if turned off and could be used if
you are experiencing reliable transfers and flashing.
## Exit options
Option ( R ) - Reboot
Execute a cold reboot. This should be done after a successful update. If
you perform a cold reboot after a failed update then it is likely that
your system will be unusable and removing and reprogramming the flash
will be required.
Option ( Q ) - Quit to boot loader.
The SBC Boot Loader is reloaded from ROM and
executed. After a successful update a Reboot should be performed. However,
in the case of a failed update this option could be used to attempt to
load CP/M and perform the normal x-modem / flash process to recover.
## CRC Utility options
Option ( 1 ) and ( 2 ) - Calculate and display CRC32 of 1st or 2nd 512k ROM.
Option ( 3 ) - Calculate and display CRC32 of a 1024k (2x512Kb) ROM.
Can be used to verify if a ROM image has been transferred and flashed correctly. Refer to the Teraterm section below for details on configuring the automatic display of a files CRC after it has been transferred.
In Windows, right clicking on a file should also give you a context menu option CRC SHA which will allow you to select a CRC32 calculation to be done on the selected file.
## Tera Term macro configuration
Macros are a useful tool for automatic common tasks. There are a number of instances where using macros to facilitate the update process could be worthwhile if you are:
* Following the ROMWBW development builds.
* Doing lots of configuration changes.
* Doing development on ROMWBW drivers
Macros can be used to automate sending ROM updates or images and for my own purposed I have set up a separate macro for transferring each of the standard build ROM, my own custom configuration ROM and update ROM.
An example macro file to send an *.upd file, using checksum mode and display the crc32 value of the transmitted file:
As identified in the introduction, there are limitations on serial speed depending on processor speed and flow control settings. Listed below are some of the results identified during testing.
Platform / Configuration | Processor Speed | Maximum Serial Speed
@@ -11,11 +11,8 @@ companion documents you should refer to as appropriate:
of RomWBW. It includes a reference for the RomWBW HBIOS API
functions.
* $doc_romapps$ is a reference for the ROM-hosted applications provided
with RomWBW including the monitor, programming languages, etc.
* $doc_apps$ is a reference for the OS-hosted proprietary command
line applications that were created to enhance RomWBW.
* $doc_apps$ is a reference for the ROM-hosted and OS-hosted applications
created or customized to enhance the operation of RomWBW.
* $doc_catalog$ is a reference for the contents of the disk images
provided with RomWBW. It is somewhat out of date at this time.
@@ -391,7 +388,7 @@ At the Boot Loader prompt, you can type `H <enter>` for help. You
can type `L <enter>` to list the available built-in ROM applications.
If your terminal supports ANSI escape sequences, you can try the
'P' command to play a simple on-screen game. Instructions for the
game are found in $doc_romapps$.
game are found in $doc_apps$.
If all of this seems fine, your ROM has been successfully programmed.
See the [Boot Loader Operation] section of this document for further
@@ -645,7 +642,7 @@ return to the Boot Loader menu. If you are interested in creating a
custom application to run here, review the "usrrom.asm" file in the
Source/HBIOS folder of the distribution.
Each of the ROM Applications is documented in $doc_romapps$. Some
Each of the ROM Applications is documented in $doc_apps$. Some
of the applications (such as BASIC) also have their own independent
manual in the Doc directory of the distribution. The OSes included
in the ROM (CP/M 2.2 & Z-System) are described in the Operating Systems
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Wayne Warthen