This manual will explain how to modify programs for both of these approaches. PQXT supports both approaches in a manner transparent to the user.
In brief, the process for ROMing an application is:
Drive C, the ROM Disk contains MS-DOS 3.3, PoqetTools, and various utilities which we have placed in ROM. Drive D is a RAM disk with a separate 24Kb silicon hard disk, used for temporary storage of files. Drive D is erased when the computer is reset. RAM cards can be used to store information on PQXT.
ROM cards, with burned in software, or SRAM cards with down-loadable software are usable in the memory card slots. OTP (One Time Programmable), EPROM, EEPROM, and Flash cards are also available for use with the system.
Some of these innovations are important for programmers porting software to our machine. The PQXT is fully XT compatible computer. However, because of Poqet's unique technologies, optimum power consumption and performance can be achieved by using Poqet's extended BIOS calls instead of direct hardware calls. (See Chapter 2 for more information about the extended BIOS functions.)
Specifications of PQXT
Separate commands must be used to program the cards using the ThinCard Drive. For example, TCERASE and TCXCOPY are used in place of the MS-DOS commands FORMAT and COPY. Unlike standard DOS media, Flash cards are not "byte alterable." This means the card must be erased in blocks (usually matched to a single chip in the card) instead of bytes. Flash cards are presently available in 1MB, 2MB, and 4MB sizes.
OTP cards have the ability to have information stored on them a single time. These ROM cards are used for custom programming of applications produced in lower numbers. Once the cards are "burned in," that information is permanently stored on the card and can not be erased or altered. These cards are ideal for storing applications or files that will not change. They are also useful for programming a quantity of cards too low to be produced on Masked ROM.
Programs should be tested and very stable before the cards are burned. Another area of caution is that OTP cards can't be tested by the manufacturer since verifying cards requires them to be programmed. This means if any of the semi-conductor components on the card have failed the card will fail during the programming process. OTP cards can be programmed on a desktop PC that is equipped with a PC card drive. The ThinCard Drive, for example, programs cards at the rate of about 40 minutes per megabyte. Like Flash, special commands are used to write data to OTP cards. OTP cards are available in 1MB, 2MB, 4MB, and 8MB sizes.
Figure 1-1
Memory SRAM Flash OTP Masked
Type ROM
----------------------------------------------------------------
Cost per High Medium Low Very Low
MB
----------------------------------------------------------------
Highest 2MB 4MB 8MB 8MB
Capacity
----------------------------------------------------------------
Write to Many External of Once Once
PC card PQ only
----------------------------------------------------------------
Economic Single Single <20 +1500
Quantities
----------------------------------------------------------------
Most File Applications/ Beta Applications
common use Storage Stable Applications
Databases
While this concept is useful for new product design, it is more critical that the current software be ported into a ROM environment. A program that is executable from ROM as well as RAM is the ideal design for our environment. RAM, limited to 640k (models 0181 and higher), is a precious commodity, and our EMS scheme allows for programs to be executed directed from ROM. There are some caveats and architectural considerations regarding the modification of programs to execute from ROM.
Some critical concerns when ROMing software include:
In summary, the advantages of compressing a program can vary dramatically for different jobs depending on the variables discussed earlier. To gain the most from compression requires experimenting with these variables until the best solution is found. However, the savings, when used intelligently, can be dramatic.
The general steps to create a ROM executable program are given below:
There are two methods of getting your application to a media that PQXT can read. The first is using a ROM or OTP card.
The second method is using a RAM card in your development process. These cards work well early on in your development process, when you are making code changes. Move the RAM card's write protect switch to the On position to create a "virtual" ROM card. When you are in final quality assurance testing, OTP cards are used.
During these early stages of development, it is a good idea to evaluate whether XIP (execute in place) or file compression technology make sense.
If the program is now to execute from ROM, re-testing of your program (even if it was already thoroughly tested) is necessary. It should be tested under various MS-DOS error conditions, and in the Read/Write modes of the program. Also, test the program for memory management problems including potential conflicts with other TSR programs.
The best media type can be determined by the size of the application, the need for updates to the files and the number of cards to be programmed.
This last step requires determining the number of units to be ordered. This, of course, determines the unit cost.
The ROM BIOS Memory Manager (LIM-MC) functions are available to systems and applications developers who need to page in and out internal and external memory devices, such as credit card memories and internal ROMS. These functions are handled through the standard LIM EMS memory function handler -- INT 67h.
Requests are made to Extended ROM BIOS services for memory paging. A scheme similar to LIM EMS 4.0 is used for page swapping. The interface and concept is thus familiar to application and system developers.
The required sequence for accessing/executing expanded memory is show below:
PCMCIA is a non-profit trade association with over 200 members. The association's primary objectives are to establish worldwide standards for PC cards and to promote the benefits of PC card technology. To ensure that PC card standards are accepted worldwide, PCMCIA coordinates their activities with JEIDA (Japanese Electronics Industry Development Association). PC cards are currently available in several forms including SRAM, ROM, OPT ROM, EPROM, EEPROM, and Flash types. PQXT accepts PC cards conforming to PCMCIA 1.0 and JEIDA 3.0 standards. However, because PQXT was introduced before the completion of the PCMCIA 1.0 standards, the cards differ in the following ways:
Pin Function Difference from PCMCIA
-------------------------------------------------------------------
Pin 16 RDY/BSY Can't monitor card's state. This is helpful
when working with EEPROMS.
Pin 18 Vpp1 No programming voltage1.
Pin 43 RFSH Can't use PSRAMS.
Pin 52 Vpp2 No programming voltage1.
Pin 54 A23 Can't address past 8 MB.
Pin 55 A24 Can't address past 16 MB.
Pin 56 A25 Can't address past 32 MB.
Pin 61 REG Can't access Attribute memory.
Pin 62 BVD2 The card shows low battery even when the
battery is dead.
Pin 63 BVD1 The card shows low battery even when the
battery is dead.
If you plan to purchase PC cards from a vendor other than Poqet
contact Poqet Customer Service first, to ensure the cards are fully
compatible. Current PC card standards define two form factors, Type
I and Type II. These cards operate identically varying only in their
thickness.
Note: Type II cards are not currently supported by PQXT.
For additional information or specifications of PC cards, contact PCMCIA at
PCMCIA Administrative Office
1030B East Duane Ave.
Sunnyvale, CA 94086
(408) 720-0107
Function 1: Get Status
Passed
AH 40h
Returns
AH Error Code
Function 2: Get Page Frame Address
Passed
AH 41h
Returns
Error Code
Function 3: Get Unallocated Page Count
Passed
AH 42h
Returns
Error Code
If AH=0,
BX Number of allocated pages
DX Total number of pages
Function 4: Allocate Pages
Passed
AH 43h
BX Number of Pages Needed
Returns
AH Error Code
if AH=0 DX LIM-MC handle (range 1-FFH)
Function 5: Map/Unmap Handle Pages
Passed
AH 44h
AL Physical Page Number
BX Logical Page Number
DX LIM-MC Handle
If ES:DI points to Device ID RMMDEVXX
CX Device ID
0 Drive A:
1 Drive B:
2 Intemal ROM
Otherwise, Extended Memory is assumed.
Returms
AH Error Code
Function 6 Deallocate Pages
Passed
AH 45h
DX LIM-MC Handle
Returns
AH Error Code
Function 7: Get Version
Passed
AH 46h
Returns
AH Error Code
AL Version Number
AL is returned as major/minor BCD version number:
0001 0000 1.0
Function 12: Get Handle Count
Passed
AH 48h
Returns
H Effor Code
X Total number of open Handles
Function 13: Get Handle Pages
Passed
AH 4Ch
DX LIM-MC Handle
Returns
AH Error Code
BX Number of pages allocated to Handle
Error Codes
00 Successful
80h Memory Manager SW Malfunction
81h Memory Manager HW Malfunction
83h Invalid Handle
84h Invalid Function Request
85h All Handles Used
86h Page Mapping Context Error
87h Not Enough System Memory
89h Attempt to Allocate 0 pages
8Ah Logical Page out of Range
8Bh Physical Page of Range
8Fh Invalid Parameter
The longest available contiguous block of internal memory is 192K (i.e. twelve 16K pages). The available internal memory map address space used is in the range of C0000h--EFFFFh.
Function Name
-------------------------------------------
1 Get Status
2 Get Page
3 Get Unallocated Page Count
4 Allocate Functions
5 Map/Unmap Handle Page
6 Deallcate Pages
7 Get Version
12 Get Handle Count
13 Get Handle Pages
ROM Card Signature DB 4Ch, 59h
Length of card in 64k blocks DW ?
Signature ID DB "ROMXXXXX0"
Number of File Header Blocks DW ?
ROM Header Version - MAJOR DB
- MINOR DB 0
Reserved DB 15 DUP (?)
ROM Checksum DB ?
Total: 32 BYTES
NAME (space filled) DB "XXXXXXXX"
NAME EXTENSION (space filled) DB "YYY"
MAIN entry point off-set DD word ptr
Reserved DB 17 DUP (?)
Total: 32 bytes
Note: Version 1.0 of the PQ-BIOS supports only the following possible configuration for mixed mode:
Disk structure at OFFSET 0 from start of card
MAIN HEADER following ROM disk, on a 64K segment boundary
CS=Relevant LIM-MC Page Swap Segment (PSS), plus adjustment for Header and FHBs
IP=MAIN entry point offset
e.g. if the 'C0000' PSS is used, the entry point to the code is at offset 19h, and there is one FHB, CS:IP is set to: C000:0059