Anyone have a memory test program for Z80 based S-100?
mdnt...@aol.com
Hi,
I recently got my S-100 hardware ironed out and working. It
consists of:
- Cromemco ZPU 4mhz Z80
- Compupro Ram17 64k
- Compupro Disk 1 floppy controller
- Compupro System Support 1
- Imsai 8080 CPA
- 2 x Shugart 800 8" floppy drives
(also interfaced to IBM PC for 8" diskette imaging and file
transfer)
Thanks to Michael Louis of California, I have this system booting
Compupro CP/M 80 version N.
I'm wanting to put together an EPROM residing at F000-FFFF
consisting of routines similar to what the Apple II has... a monitor,
debugger, miniassembler, and some POST routines so I can know the
hardware is functional. I have the hardware set for a power on jump
to F000; and a reset jumps to 0000 (for Disk 1 booting eprom). I
might try to transfer to boot eprom routines to my main resident eprom
as well.
To begin with, does anyone have the source code to a simple
POST-style RAM testing program that I could either learn from or
relocate into my eprom?
Respectfully,
John
French Luser
> I recently got my S-100 hardware ironed out and working.
Good.
> I'm wanting to (... have ...) a monitor,
> (...) so I can know the
> hardware is functional.
Excuse me, but I find a contradiction in your quest.
The contradiction is that any monitor in ROM will need
that the CPU is working, while the hardware (and I mean
all the hardware, even the CPU!) can be tested by a front-panel...
(many years ago, there were several messages about
front panels in the comp.os.cpm Newsgroup that I found interesting).
> To begin with, does anyone have the source code to a simple
> POST-style RAM testing program that I could either learn from or
> relocate into my eprom?
In summary, you scan the (allowable) RAM, write one byte
value (or all the 256 values) in a memory cell (usually a byte),
then read it back, either right after writing it or after a while,
then continue until the end of RAM.
Since this is a program, it can be a CP/M COMmand file.
Also, since speed is not important, it can be coded in BASIC.
In fact, all the elements that you mention for your monitor
could be written in interpreted BASIC. It is only if you
insist on putting them in a ROM that writing them in
assembler would be needed. But you would lose
2 or 3 Kbytes of memory... and the monitor would
run only if a good deal of the system was running.
Personally, I would add a front panel to the system,
rather than a monitor in ROM.
Yours Sincerely,
"French Luser"
David Tweed
> To begin with, does anyone have the source code to a simple
> POST-style RAM testing program that I could either learn from or
> relocate into my eprom?
I don't have source code, but to counter the French Luser's advice,
I thought I'd write down some general thoughts about such a program.
A POST-type RAM test wants to cover some basic potential faults in
your memory, mostly stuck-at faults (opens, shorts to supplies) and
shorts between signals (address lines, data lines).
It needs to do its work with a minimum of hardware resources -- in
particular, without relying on the RAM being tested -- usually just
the CPU chip and its oscillator, the ROM containing the code and
the connections among those items. (This is known as the "minimal
functional core" of the system. The whole point of POST is to
incrementally add known-good hardware to this core until the
whole system is up.)
There is a question of how much RAM is in (or is supposed to be in)
the system. You'll either need a way of telling the program how much
RAM to test, or you can use the RAM test to "discover" how much
usable RAM is in the system (like on a PC) and tell the rest of the
system software about it.
Finally, there is the question of how the RAM test reports its
results, and how much detail is contained in the report. Perhaps
you have some LEDs or a video screen buffer, and the test simply
displays the first failing address. If you have a terminal of some
sort attached to the system, the test program needs to know how to
send it text.
Since you can't rely on RAM, you need to jump to your RAM test and
then jump back out (no stack usage). Since most 8080/Z-80 systems
have RAM starting from 0x0000, the program usually just needs to
know where the end of memory is expected to be, and this needs to
be passed in via a register. Success/failure indicators need to be
passed out in registers as well.
A good start for testing is a "checkerboard" pattern. Write
alternating 0x55 and 0xAA to all available RAM, then read it
back. Do it again using 0xAA alternating with 0x55. Now you've
verified that all RAM cells can be set to both 0 and 1, there
are no stuck bits on the data bus and adjacent data bits are
not shorted together.
To check for address errors, a good test is to write all of RAM
with its own address ("address as data" test) and then read it
back. Any problems here will indicate a stuck address bit or
adjacent address bits shorted together.
That's usually about it for a POST-type test. More extensive RAM
testing is usually handled by a loadable program once you have
a known amount of working RAM.
The only other thing that I can think of is if you have DRAM in
the system, you might do a "refresh test". This consists of doing
one or more of the above tests with a long pause (several seconds)
between the writing phase and the reading phase. Make sure that
there is minimal bus activity during the pause -- sometimes such
activity can keep DRAM refreshed even if the actual refresh logic
isn't working correctly. Any errors found here indicate problems
with the refresh hardware.
-- Dave Tweed
mdnt...@aol.com
So far, thank you both for your detailed responses.
I tend to agree with David on the usefulness of having a POST, the
functional core concept, and the incremental adding of tested hardware
to this core until the system is fully up. That's exactly what I'm
trying to do.
I am running an Imsai front panel... but that's of no efficient use
when trying to ascertain whether all my RAM chips are good upon
startup.
I have managed thus far to locate the source code to a Heath H17 ROM --
which has a memory test in it. Also found on Alibris a book by
Phoenix on the early IBM PC/XT/AT Bioses... so perhaps that can give me
a POST framework to emulate.
Part of my struggle here is that I'm also having to re-learn assembly
language.. been 20 years.. so I thought the memory test would be a nice
refresher.
French, I am trying to end up with an upper 2k-16k of my 64k system
being in ROM... modeled after the Apple II and IBM PC approaches.
The great thing about the Apple II is that you can just turn it on,
program in Basic, assembly, or machine language, and save to
tape..without ever booting a disk. Obviously, you can boot from a disk
too.
The rom-based PC Bios was revolutionary in how it abstracted the
hardware from the OS.. such that any copy of DOS would boot out of the
box with any PC bios compatible machine.. a huge (but debatable)
improvement over the machine-specific CP/M versions or doing the CP/M
building and CBIOS customizing yourself. I think this is one of the
significant reasons why the PC soon surpassed the S-100.
All that said, my interest in the PC Bios is only twofold: one, for
its POST routines; and two, that it might be interesting just an
exercise, to attempt to put the CP/M Cbios into EPROM, and try making
CP/M operate as DOS would.. by referring to the CP/M bios instead of
the linked one.
~ J
nos...@nouce.bellatlantic.net
wrote:
Have a look at http://www.dunfield.com/downloads.htm#freeware
ALPS.ZIP.
I know it's only 8085 but it's a starting point and I've used it.
Shouldn't be hard to "z80" it though it will run as is on z80.
If you want a debugger and inline asm find ZSID or ZDDT (google)
as they are out there and could be modified for standalone use.
As to memory test, KISS. Try a simple write FFh test for FFh
then write 00H test for that, the sequentially number so 00-FFh
lines up on even page boundries, check to see you get that back.
If you think your seeing pattern sensitivity there are otehr patterns
to run but I'd guess you need an 'is it really ram and are the address
lines ok' sort of test.
Allison
s_dub...@yahoo.com
Come to think about it, IIRC, there's a memory test routine it the DDT
source for the S set command.
French Luser
> French, I am trying to end up with an upper 2k-16k of my 64k system
> being in ROM... modeled after the Apple II and IBM PC approaches.
> The great thing about the Apple II is that you can just turn it on,
> program in Basic, assembly, or machine language, and save to
> tape..without ever booting a disk. Obviously, you can boot from a disk
> too.
I also happen to be a fan of ROM-booting OSes (I hope to do this
for CP/M-86 Plus).
Now, since we are talking about CP/M 2.2 and ROM-booting,
could I remind you that "Personal CP/M" (whose source code
is available...) is just one such thing? Also, it is CP/M version 2.8
and probably uses BDOS 3, since it can deal with 512 MB HDs...
(The only problem is that no written paper doc has been found, so far.
I was once promised, several years ago, a photocopy of the 3 manuals
by an Englishman, but never received anything.)
If you search for "Personal CP/M" on the Internet, you will find
2 hand-held "PDAs" that used it, one American, and the other English.
I once corresponded with the English selling it, but he realized that
he was in short supply of his remaining devices, and finally refused
to let me buy one (they were used by factories). If you could buy one
copy of the American system, then find its paper doc, you would
have done something useful for CP/M (and could set up a Web page
dealing with "Personal CP/M" telling us more about it).
Yours Sincerely,
"French Luser"
nos...@nouce.bellatlantic.net
<Bill....@microsoft.com> wrote:
>Hello, John!
>
>> French, I am trying to end up with an upper 2k-16k of my 64k system
>> being in ROM... modeled after the Apple II and IBM PC approaches.
>> The great thing about the Apple II is that you can just turn it on,
>> program in Basic, assembly, or machine language, and save to
>> tape..without ever booting a disk. Obviously, you can boot from a disk
>> too.
>
>I also happen to be a fan of ROM-booting OSes (I hope to do this
>for CP/M-86 Plus).
Easy to do. Did it around 1981. You have to move all the
data areas out of the romspace if you want to run from rom.
However, it may affect the compatability of the code with some
CP/M-86 aps. If you want to boot from rom (copy to ram) you can
use any image.
None of the 8080/z80 versions of CP/M can be rommed without
recompiling to move data areas out to ram. The internal structures
must be kept in the same relative address or application that call
into CP/M (bad but, used) will fail. I'm currently running a system
this way (from ROM) and have a Epson PX-8 that does it as well.
Works very well.
>Now, since we are talking about CP/M 2.2 and ROM-booting,
>could I remind you that "Personal CP/M" (whose source code
>is available...) is just one such thing? Also, it is CP/M version 2.8
>and probably uses BDOS 3, since it can deal with 512 MB HDs...
Really, since the code is also V2.2 which truncates at 8mb and it's
only using 128byte logical sectors. I can't see how 512mb is possible
with out many partitions mounted. Unless your refering to cpm-86
and thats a different beast internally.
CP/M+ or V3 could only handle logical drives to 32mb as was the case
for MPM as well. Though you could have up to 16 logical drives
(partitions) of 32mb each. (strictly 8080/z80 version)
PCPM (8080) is CPM V2 with functions 45 (set error return) and
48(flush biffers) added. Nice but the code is nearly the same as
V2.2 without the additions. putting this in rom would be the same
exact task as V2.2. One differnce is very few CP/M 80 applications
would require the added functions and they are different than CPM+
or MPM. the internal math limits it to 8mb logical disks just like
V2.2 (same exact routines).
PCPM-86, never saw a version above 2.01 in source. Putting this in
rom is the same problem, moving data areas. Also a different loader
startup code will be needed to perform the cold boot functions that
were nominally in rom and used to get code off disk to start up.
Allison
nos...@nouce.bellatlantic.net
wrote:
>French, I am trying to end up with an upper 2k-16k of my 64k system
>being in ROM... modeled after the Apple II and IBM PC approaches.
> The great thing about the Apple II is that you can just turn it on,
>program in Basic, assembly, or machine language, and save to
>tape..without ever booting a disk. Obviously, you can boot from a disk
>too.
Apple also did things to page roms in and out of the memeory map
to permit greater ram space.
>The rom-based PC Bios was revolutionary in how it abstracted the
>hardware from the OS.. such that any copy of DOS would boot out of the
>box with any PC bios compatible machine.. a huge (but debatable)
>improvement over the machine-specific CP/M versions or doing the CP/M
>building and CBIOS customizing yourself. I think this is one of the
>significant reasons why the PC soon surpassed the S-100.
Actually the concept of BIOS is CP/M of not less than five years older
than PCdos. The Concept is still valid today.
The differnce of the PC vs CP/M was that CP?M the BIOS could be user
written for varibale hardware and disks. It is the abstaction layer.
PC passed S100 for many reasons, lower cost to produce, smaller size
and standardized but not always the best hardware archetecture. (S100
systems existed with every intel cpu up to the 386 as well as
Motorola, TI, and most everyone else from 8 bit through 32bit. That
variability of S100 meant a standardiazed BIOS (one size fits all) is
far less likely to happen, though there were vendors within their
product line that did that. However S100 and other busses lived on
for a lot of years because you could build exactly what you needed
like a PC like machine with 900k of ram.
>All that said, my interest in the PC Bios is only twofold: one, for
>its POST routines; and two, that it might be interesting just an
>exercise, to attempt to put the CP/M Cbios into EPROM, and try making
>CP/M operate as DOS would.. by referring to the CP/M bios instead of
>the linked one.
CP/M V2.2 BIOS is easy to put in rom as a package with a Monitor
program and bios. All that is needed is create your rom monitor with
the CBIOS code in it (respecting that some of the CBIOS must be in
ram) and build a version of CP/M that is just below the romspace.
This is not uncommon and has been done by many others beside
myself.
CP/M expectation is:
CCP|BDOS|BIOS jumptable are contigious. The jump table can refer
to bios code anywhere in memory. There are obvious caveats such as
you can't just put the bios code where user program go. There is a
lot of wiggle room as to how all that fits together and it can include
banked ram and rom spaces.
A suggested map is rom a E000--> EFFFh and ram at F000h
and above. That allows 4k of rom (enough for decent monitor and
BIOS code) and space for monitor and BIOS tables in ram above.
The resulting system from CP/M perspective is 56k (Plenty of space).
The only extra effort is making sure the needed tables and areas that
must be in ram are initialized by COLDBOOT and WARMBOOT
sections of the BIOS.
A feature that is nice is with a monitor resident at reset makes
software debug easier and during BIOS development it can be
indispenseable.
I've done this and have several systems that do exactly that and
its very easy to work with. On variation is rather than load CPM from
disk I copy it from eprom and then hide the eprom for both a fast
boot and no need to have it on system tracks. As a result the base
system will boot with a formatted disk.
As an aisde. I've had at least two PCs that passed post but had
severe memory corruption problems. POST coverage is less
than 80% and some hardware was not tested at all or sufficiently
leading to problems. POST is not a panacea.
Allison
John Elliott
: PCPM (8080) is CPM V2 with functions 45 (set error return) and
: 48(flush biffers) added. Nice but the code is nearly the same as
: V2.2 without the additions. putting this in rom would be the same
: exact task as V2.2.
Source exists for the PCP/M-80 BDOS, and one of the equates is 'data_low'.
If this is set, it looks like the BDOS ends up in ROM, and LDIRs its
internal variables into RAM when the "?bdosc" or "?bdosw" entry points
are called:
if data_low
ld bc,front_size ;move an image of the front of the BDOS code
ld de,bdos$dt ;segment to the front of the data segment for
ld hl,bdos$cd ;systems with data lower in RAM
ldir
endif
: PCPM-86, never saw a version above 2.01 in source. Putting this in
: rom is the same problem, moving data areas. Also a different loader
: startup code will be needed to perform the cold boot functions that
: were nominally in rom and used to get code off disk to start up.
The Philips :YES is supposed to have DOS Plus in ROM; that has the same
kernel as PCP/M-86 v2.0/4. I haven't got a copy of the ROM image so I don't
know how it was done.
--
John Elliott
nos...@nouce.bellatlantic.net
<j...@seasip.demon.co.uk> wrote:
>nos...@nouce.bellatlantic.net wrote:
>: PCPM (8080) is CPM V2 with functions 45 (set error return) and
>: 48(flush biffers) added. Nice but the code is nearly the same as
>: V2.2 without the additions. putting this in rom would be the same
>: exact task as V2.2.
>
> Source exists for the PCP/M-80 BDOS, and one of the equates is 'data_low'.
>If this is set, it looks like the BDOS ends up in ROM, and LDIRs its
>internal variables into RAM when the "?bdosc" or "?bdosw" entry points
>are called:
>
> if data_low
> ld bc,front_size ;move an image of the front of the BDOS code
> ld de,bdos$dt ;segment to the front of the data segment for
> ld hl,bdos$cd ;systems with data lower in RAM
> ldir
> endif
That can be tweeked as needed.
>: PCPM-86, never saw a version above 2.01 in source. Putting this in
>: rom is the same problem, moving data areas. Also a different loader
>: startup code will be needed to perform the cold boot functions that
>: were nominally in rom and used to get code off disk to start up.
>
> The Philips :YES is supposed to have DOS Plus in ROM; that has the same
>kernel as PCP/M-86 v2.0/4. I haven't got a copy of the ROM image so I don't
>know how it was done.
The tandy HX1000 is a dos in rom somewhat PC compatable machine.
Actually sort of nice to play with.
Allison
French Luser
> Come to think about it, IIRC, there's a memory test routine it the DDT
> source for the S set command.
DDT and SID check if they are dealing with RAM or ROM
by checking if they can write back the byte read.
Yours Sincerely,
"French Luser"
French Luser
> PCPM (8080) is CPM V2 with functions 45 (set error return) and
> 48(flush biffers) added. Nice but the code is nearly the same as
> V2.2 without the additions. putting this in rom would be the same
> exact task as V2.2.
You seem to be more knowledgeable about Personal CP/M
than me. If you are sure than the code is almost identical,
then Personal CP/M was the last version using BDOS Version 2,
and would thus be limited to 8 MegaBytes for its file/HD size.
(BDOS Version 3 has a 32 MB limit for a file, and 512 MB
for the drive.) The only thing that I know about Personal CP/M
are the various comments dealing with it (for example, by
Sol Libes) that I republished over the years in the comp.os.cpm
Newsgroup.
As for ROM-booting CP/M-86 Plus, I hope that you will find
the following interesting:
CPMPSGG.WS4 (= "CP/M-86 Plus System Guide", appendix G)
-----------
(Edited by Emmanuel ROCHE.)
Appendix G: Placing CP/M-86 Plus in ROM
---------------------------------------
The CP/M-86 Plus operating system was developed with separate code and
data,
to allow you to place CP/M-86 Plus in ROM. The contents of the CPMP.SYS
file,
code and initialized data, are placed in ROM and, at power-on or
hardware
reset, the data is copied to RAM. This appendix assumes familiarity with
the
material covered in Sections 9 and 10 on using GENCPM and BIOS debugging.
You supply a "data mover" routine that receives control when the 8086 or
8088
is reset, and copies the initialized data from the ROM to RAM. Figure
G-1
shows one possible CP/M-86 Plus ROM image. In this example, at
location
0FFFF:0000h is a JMPF (Jump Far instruction) to the START_MOVER: label at
a
lower memory location in the ROM. The data mover must exit by setting DS
to
the SYSDAT segment, and performing a JMPF (Jump Far instruction) to
the
beginning of the BDOS code.
CPMP.SYS File CP/M-86 Plus in ROM
Image (high memory)
+---------------------------+
| JMPF START_MOVER | <--- 0FFFF:0000h
: :
+----------+ ---> +---------------------------+
| CPMP.SYS | | SYSDAT |
|Data Group| | (BDOS/BIOS Data Segment) |
+----------+ ---> +---------------------------+
| | | CCP Data Group (Optional) |
| | +---------------------------+ <--- ROMing data base
| CPMP.SYS | | CCP Code Group (Optional) |
| Code | +---------------------------+
| Group | | BIOS Code Segment |
| | +---------------------------+
| | | BDOS Code Segment |
+----------+ ---> +---------------------------+ <--- OSBASESEG
| CPMP.SYS | | Data Mover |
|CMD Header| +---------------------------+ <--- START_MOVER
+----------+
(CPMP.SYS)
Figure G-1. An Example CP/M-86 Plus ROM Image
Figure G-2 shows the execution image after the initialized data has been
moved
to RAM.
. +---------------------------+
. | JMPF START_MOVER | <--- 0FFFF:0000h
. : :
. +---------------------------+
| SYSDAT |
R | (BDOS/BIOS Data Segment) |
+---------------------------+
O | CCP Data Group (Optional) |
+---------------------------+
M | CCP Code Group (Optional) |
. +---------------------------+
. | BIOS Code Segment |
. +---------------------------+
. | BDOS Code Segment |
. +---------------------------+ <--- OSBASESEG
. | Data Mover |
. +---------------------------+ <--- START_MOVER
. | TPA |
. : :
. | (Transient Program Area) |
+---------------------------+ <--- OSENDSEG
R | Uninitialized Data |
| Buffers |
A +---------------------------+ <--+
| SYSDAT | |
M | (BDOS/BIOS Data Segment) | | Area copied
. +---------------------------+ | from ROM
. | CCP Data Group (Optional) | |
. +---------------------------+ <--+
. | TPA |
. : :
. | (Transient Program Area) |
. +---------------------------+
Figure G-2. CP/M-86 Plus Code in ROM and Data in RAM
In Figure G-2, OSBASESEG is the starting paragraph of the operating
system
code, and OSENDSEG is the next paragraph after the operating system RAM
area.
The size of the ROM required depends on the size of the BIOS, and also if
you
make the CCP a permanent part of the Operating System. The BDOS alone is
about
21 Kbytes. The CCP is an additional 5 Kbytes.
The answer to the GENCPM "Code Base of CP/M-86 Plus" question (see Section
9)
sets the segment address where CP/M-86 Plus code must be located in RAM
or
ROM. The answer to the GENCPM "Data Base of CP/M-86 Plus" question
(see
Section 9) determines the RAM segment address where the uninitialized
and
initialized data areas must reside. The area in RAM reserved by GENCPM for
the
data must be large enough to contain both the initialized data and
the
uninitialized data required by the operating system. Note that the
CPMP.SYS
file created by GENCPM contains only the initialized data. See Figure E-2.
GENCPM displays the length in paragraphs of the operating system code,
the
initialized system data, and the total system data at the end of a
GENCPM
session (see Figure 9-8). The total system data is the sum of the
initialized
and uninitialized data. GENCPM resolves all references to the system
data.
GENCPM also adjusts the Memory Descriptors in the BIOS Kernel Data Header,
to
exclude the data area reserved for the operating system. The following is
an
example of the GENCPM display when the system code is set at segment
0F800h,
and the system data at 40h:
CP/M-86 Plus ROMing Information
Base Length
---- ------
System Code F800h 04F0h
Initialized System Data 0040h 0179h
Total System Data 0040h 0514h
Operating System Memory Table:
Partition Base Length
------------------------
0 0554h 1AECh
CPMP.SYS file created on drive D:
*** CP/M-86 Plus SYSTEM GENERATION DONE ***
Figure G-3. GENCPM ROMing Information Screen
Listing G-1 shows an example data mover using this GENCPM information.
At
power-on or after a hardware reset, the hardware must transfer control to
the
START_MOVER: label.
Note: The SYSDAT value is found in the word at offset 6 within the BDOS
code
segment. When the CCP is made part of the system, the RAM data area
begins
with the CCP data, and not with the SYSDAT data segment.
Listing G-1. Example ROM Data Mover
; Construct a ROM image file using this program (DMOVER.A86),
; the CPMP.SYS file, and the following instructions:
;
; A>rasm86 dmover ;assemble this program
; A>link86 dmover.sys=dmover
; A>sid86
; #rdmover.sys
; START END
; ZZZZ:0000 ZZZZ:01FF ;create a file containing
; #wdmover,80,ff ;the 1st 128 bytes of code
; #^C ;from this program
; A>sid86
; #rcpmp.sys
; START END
; ZZZZ:0000 ZZZZ:XXXX ;strip the CMD file Header Record
; #wcpmp,80,XXXX ;from the CPMP.SYS file
; #^C
; A>pip rom.sys=dmover[o],cpmp[o]
;
; The file ROM.SYS has the format:
;
; (file start) (file end)
; +------------+-------------+-------------------------+
; | Mover Code | System Code | Initialized System Data |
; +------------+-------------+-------------------------+
false equ 0
true equ not false
sysdat equ word ptr .6
debug equ true
if debug
SYSTEM_CODE equ 2000h
endif
if not debug
SYSTEM_CODE equ 0F800h
endif
CODE_LENGTH equ 4F0h ;as displayed by GENCPM
INIT_DATA_LENGTH equ 179h ;as displayed by GENCPM
INIT_DATA_IN_ROM equ SYSTEM_CODE + CODE_LENGTH
INIT_DATA_IN_RAM equ 3000h
CSEG
start_mover: ;JMPF instruction at 0FFFF:0000h goes here
;-----------
; Entry: none required
; (after reset to 8086 or 8088
; DS,ES,SS = 0, flags are reset, and
; all other registers are unknown)
; Exit: DS = SYSDAT
; JMPF's to start of BDOS
mov ax,INIT_DATA_IN_ROM
mov ds,ax ;start of data to move
mov cx,INIT_DATA_LENGTH*8 ;words of initialized data
mov ax,INIT_DATA_IN_RAM
mov es,ax ;ES=RAM destination for
xor si,si ;DS=ROM source of initialized data
mov di,si ;DI=SI=0
rep movsw ;copy from ROM to RAM
mov ax,SYSTEM_CODE
mov ds,ax
mov ds,sysdat ;get SYSDAT segment address
;out of BDOS code
jmpf cs: dword ptr bdos_init ;transfer control to BDOS
bdos_init dw 0
dw SYSTEM_CODE
The example data mover is made into a 128-byte file by the SID-86
command
shown in the comment that begins the mover listing. The 128-byte length
is
used for simplicity and ease of manipulation. Your data mover can certainly
be
smaller if need be. After the initialized data is moved, the data mover
must
set the DS register to the SYSDAT segment, then perform a JMPF to
the
beginning of the BDOS code. The SYSDAT data segment address is found at
offset
6 within the BDOS code segment.
To debug a data mover similar to the example in Listing G-1 under CP/M-86
1.X
or CP/M-86 Plus, create the ROM.SYS file where SID-86 or DDT-86 can read
and
execute it in RAM. Set the "Code Base of CP/M-86 Plus" to this location
in
RAM, allowing 8 paragraphs for the data mover. Set the "Data Base of
CP/M-86
Plus" to a RAM area large enough for the uninitialized and initialized
data.
Additionally, the data mover must be assembled reflecting the segment
address
of where the data is to be copied. Listing G-1 includes a debug toggle
for
testing in RAM. The layout of memory for debugging the ROM.SYS file is
similar
to the layout for debugging the CPMP.SYS file, except that the CMD file
Header
Record of the CPMP.SYS file is replaced with the data mover. Section
10
discusses the debugging of the CPMP.SYS file.
When your data mover works in RAM, run GENCPM, specifying the segment in
ROM
where the system code is to reside. Answer the "Data Base of CP/M-86
Plus"
question with desired segment address in RAM for the initialized
and
uninitialized data. If you have a debug toggle in your data mover routine,
set
it to false and reassemble it. Place the CPMP.SYS file and the data mover
in
ROM, such that the data mover receives control on power-on or hardware
reset.
EOF
nos...@nouce.bellatlantic.net
<Bill....@microsoft.com> wrote:
>Hello, Allison!
>
>> PCPM (8080) is CPM V2 with functions 45 (set error return) and
>> 48(flush biffers) added. Nice but the code is nearly the same as
>> V2.2 without the additions. putting this in rom would be the same
>> exact task as V2.2.
>
>You seem to be more knowledgeable about Personal CP/M
>than me. If you are sure than the code is almost identical,
>then Personal CP/M was the last version using BDOS Version 2,
>and would thus be limited to 8 MegaBytes for its file/HD size.
>(BDOS Version 3 has a 32 MB limit for a file, and 512 MB
>for the drive.) The only thing that I know about Personal CP/M
>are the various comments dealing with it (for example, by
>Sol Libes) that I republished over the years in the comp.os.cpm
>Newsgroup.
I know nothing of it's history as it made no significant impact here
in the USA as a direct item. Generally from the code and what I've
found it's a varient of V2.2 with what I suspect are OEM specific
adjustments.
As to CP/M 3 addressing 512mb, not really. I have CPM3 on systems
and the limits are lower, 32mb. The reason it went from 8mb to 32
is the logical sector size went from 128 bytes to 512. Same math same
limits times 4. If you really want to break the 8/32mb barrier you
need P2dos/SuprBdos/NovaDos/ZRDOS as they are a series of
CP/M work a likes written from the ground up in Z80. They fix many
"broken" aspects of CP/M, add useful extensions and can address
up to 1gb.
Of course anyone thats used even 8MB cpm with a flat file system
know what a pain ploughing through over 1000 directory entries
can be.
>As for ROM-booting CP/M-86 Plus, I hope that you will find
>the following interesting:
>
>CPMPSGG.WS4 (= "CP/M-86 Plus System Guide", appendix G)
No surpize, most of the people reading that would have figured it out
from working with CP/M-86 at the implementation level.
Allison
John Elliott
: As to CP/M 3 addressing 512mb, not really. I have CPM3 on systems
: and the limits are lower, 32mb. The reason it went from 8mb to 32
: is the logical sector size went from 128 bytes to 512. Same math same
: limits times 4.
Not at the BDOS level; that still uses 128-byte records. It gives you 32Mb
by allowing 18-bit record counts in the FCB rather than 16-bit.
The maximum drive size of 512Mb is quoted in the CP/M Plus System Guide:
# CP/M 3 supports a maximum of sixteen logical floppy or hard disks with a
# storage capacity of up to 512 megabytes each. The maximum file size
# supported is 32 megabytes.
You might be limited to 32Mb if the BIOS only supported byte parameters to
SETTRK and SETSEC (giving at most 65536 sectors on disc).
--
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
nos...@nouce.bellatlantic.net
<j...@seasip.demon.co.uk> wrote:
>nos...@nouce.bellatlantic.net wrote:
>: As to CP/M 3 addressing 512mb, not really. I have CPM3 on systems
>: and the limits are lower, 32mb. The reason it went from 8mb to 32
>: is the logical sector size went from 128 bytes to 512. Same math same
>: limits times 4.
>
> Not at the BDOS level; that still uses 128-byte records. It gives you 32Mb
>by allowing 18-bit record counts in the FCB rather than 16-bit.
> The maximum drive size of 512Mb is quoted in the CP/M Plus System Guide:
Yep the fixed the truncation bug somewhat.
># CP/M 3 supports a maximum of sixteen logical floppy or hard disks with a
># storage capacity of up to 512 megabytes each. The maximum file size
># supported is 32 megabytes.
Ok, looked back and saw that. Minor brain death. Not terribly
efficient. Look at the allocation block size. For the 8086 with the
somtimes bigger programs and databases a large disk may be utility but
for smaller systems storing a copy of VEDIT in a 16 or 32k allocation
block was high wastage. Also there was the slighltly ugly problem
of fixed directory size, you either ended up with directory full
errors or a directory that took a long time to list or search (find
first function).
What CP/M doesn't have and still needs is hierachal directories. I've
done it but I don't like the method I used, it's code and it costs
speed. I really needed a linked block list allocation scheme
rather than a linked directory entry containing allocation blocks.
> You might be limited to 32Mb if the BIOS only supported byte parameters to
>SETTRK and SETSEC (giving at most 65536 sectors on disc).
No problem here always treated them as word values. That way I could
treat a ramdisk or rom disk as LBA addresses with a block being
128bytes.
Allison
Bill Sudbrink
The cromemco floppy controllers (the 4FDC and 16FDC anyway) have
ROMs with memory test routines in them. As a bonus, they will
also transfer themselves to RAM (you have to have the ROM enable
on the card set up to drive the PHANTOM line on the S-100 bus)
and test the RAM that was being hidden by the ROM.
John Elliott
: What CP/M doesn't have and still needs is hierachal directories.
For certain values of "CP/M". Apricot PCP/M-86 3.1 has at least some of
the BDOS functions that operate on directories, and the 4.1 kernel in
PCP/M-86 2.0/4 and DOS Plus certainly does support subdirectories on FAT12
and FAT16 drives.
nos...@nouce.bellatlantic.net
<j...@seasip.demon.co.uk> wrote:
>nos...@nouce.bellatlantic.net wrote:
>: What CP/M doesn't have and still needs is hierachal directories.
>
> For certain values of "CP/M". Apricot PCP/M-86 3.1 has at least some of
>the BDOS functions that operate on directories, and the 4.1 kernel in
>PCP/M-86 2.0/4 and DOS Plus certainly does support subdirectories on FAT12
>and FAT16 drives.
Win98 supports CP/M FCB, it's not CP/M.
Totally useless if the CPU is Z80 and the ODS is CP/M allocation
blocks.
The Comment was "What CP/M doesn't have and still needs is hierachal
directories" and if I wanted DOS yes it's much easier with a different
ODS. But then it's not CP/M its a hybrid. Putting directory
capabilities in most varients of CP/M has two problems it's difficult
to allocate space in the allocation block scheme without recursion
and the BDOS offers no help(unsafe for recusive file system calls in
many versions).
Allison
mdnt...@aol.com
mdnt...@aol.com
versions. By PDA, are you referring to PCPM80?
mdnt...@aol.com
Allison...@nouce.bellatlantic.net
wrote:
>Allison -- Might I have your email address?
Try KB1GMX at ARRL dot NET it's an alias that gets to me.
Allison
s_dub...@yahoo.com
-linked block list allocation-
sounds somewhat like the ISIS filesystem:
http://bitsavers.trailing-edge.com/pdf/intel/ISIS_II/ISIS_internals.pdf
I don't know how one would cram any more info into the current Dir FCB
structure.
unless one uses the cpm plus strategy of using a specified Dir code to
mark a special FCB record. Or, considering that the first (1 or more)
Block Numbers are the Directory Area - which are never found among the
Dir FCB Disk Map numbers - use those in a new strategy so that if found
in the Dir FCB Disk Map, they are interpreted as links to more SFCB's
holding path info. --just some poorly thought thru ideas.
On modern hardware, re: cp/m-86, the word sized block numbers are just
too small for LBAddressing on the modern larger hard drives. Even the
CDOS strategy of dos emulation, is hardly practical any longer.
Jack Peacock
news:43a40eb9$0$29193$8fcf...@news.wanadoo.fr...
> In summary, you scan the (allowable) RAM, write one byte
> value (or all the 256 values) in a memory cell (usually a byte),
> then read it back, either right after writing it or after a while,
> then continue until the end of RAM.
>
In most cases this is sufficient, but not for a Z80. There is one special
case, the M1 instruction fetch, which has different (i.e. shorter) timing
compared to a normal bus cycle. To make a thorough test, you have to
actually execute a program in RAM to ensure the M1 timing is long enough for
the RAM chip access time.
Jack Peacock
Barry Watzman
memory location with an actual execution fetch. I have a copy of it
somewhere.
David Tweed
> > value (or all the 256 values) in a memory cell (usually a byte),
> > then read it back, either right after writing it or after a while,
> > then continue until the end of RAM.
>
> In most cases this is sufficient, but not for a Z80. There is one
> special case, the M1 instruction fetch, which has different (i.e.
> shorter) timing compared to a normal bus cycle. To make a thorough
> test, you have to actually execute a program in RAM to ensure the M1
> timing is long enough for the RAM chip access time.
Interesting point, but not relevant.
Whether or not the memory system supports the cycle time of an M1
fetch is a design-time issue, not an issue related to a manufacturing
flaw or a fault that develops later that would be detected by POST.
The type of memory test we're talking about is looking for flaws in
the specific chips, PCBs, solder joints, connectors and other parts
used in the system.
Verifying that the design of the system is correct is an entirely
different problem, and requires a very different approach. And by
"system design", I mean things as simple as making sure you select
the right number of wait states on the memory card for the speed of
the CPU and/or backplane interface.
-- Dave Tweed
Allison...@nouce.bellatlantic.net
Good point but you forget one detail. The user is involved with
S100 based bardware so even a well designed but slow board could
fail in perplexing ways.
As often happens when reassembling older systems attention is not paid
or worse adaquate docs are not available to acertain if the specs are
met. Sometime even with the specs/docs are available there are
glaring errors (marketing hype!). I consider the problem less likely
than outright failure but experience has proven it can happen.
For most cases a simple "is memory there test" is adaquate
as pattern or other oddball problems are not often seen.
A test for refresh fail is useful (expecially for altair 88-mcd cards)
as there are many older DRAM cards that were poorly timed and
flakey.
Allison
Herb Johnson
> Jack Peacock wrote:
> > .... There is one
> > special case, the M1 instruction fetch, which has different (i.e.
> > shorter) timing compared to a normal bus cycle. To make a thorough
> > test, you have to actually execute a program in RAM to ensure the M1
> > timing is long enough for the RAM chip access time.
>
> Interesting point, but not relevant.
>
> Whether or not the memory system supports the cycle time of an M1
> fetch is a design-time issue, not an issue related to a manufacturing
> flaw or a fault that develops later that would be detected by POST.
>
> The type of memory test we're talking about is looking for flaws in
> the specific chips, PCBs, solder joints, connectors and other parts
> used in the system.
>
> Verifying that the design of the system is correct is an entirely
> different problem, and requires a very different approach. And by
> "system design", I mean things as simple as making sure you select
> the right number of wait states on the memory card for the speed of
> the CPU and/or backplane interface.
>
> -- Dave Tweed
Peacock is in fact correct. But the original question was very broadly
asked, anyway.
Z80's by chip design, fetch instructions faster than they fetch data
for I/O reads, or stack reads. (8080's don't have this feature.) Check
the specs, at least for the older Zilog chips. You have to work at the
hardware design to avoid this situation. Of course one can design any
sort of scheme.
In any event, it was common practice in the old days to have both
memory read/write test programs, AND "worm" programs. The worm tests
instruction execution success by moving itself through memory,
executing itself to display its successful location address - and
moving again, etc., until failure, leaving the last-good address on
display.
In now-old Z80 systems, memory chips are slowing down, that is their
error rates are increasing with age. You need an aggressive test like
"worm" to find the soft chips, or to inform you to add wait states or
slow down the system clock, or to use faster-rated RAM.
As to what memory test is being "talked about", the answer is that
there was no specification given. Just someone who wants some "memory
test" programs, whatever that means. Such programs are in various CP/M
archives online and on CD's, and one was posted in this thread. The
"worm" program mentioned should be in those archives; or one can write
their own for fun from the "spec" I just gave.
Herb Johnson
Herbert R. Johnson, voice 609-771-1503, New Jersey USA
<a href="http://retrotechnology.com/herbs_stuff/"> web site</a>
<a href="http://retrotechnology.net/herbs_stuff/"> domain mirror</a>
** hjoh...@njcc.com and njcc.com/~hjohnson are EXPIRED **
my email address: herbjohnson ATT comcast DOTT net
if no reply, wait & try: hjohnson AAT retrotechnology DOTT com
"Herb's Stuff": old Mac, SGI, 8-inch floppy drives
S-100 IMSAI Altair computers, docs, by "Dr. S-100"
David Tweed
> Peacock is in fact correct.
I never said he wasn't.
> In now-old Z80 systems, memory chips are slowing down, that is
> their error rates are increasing with age.
I can see that error rates might go up with age, but I'd be hard
pressed to explain how it can be attributed to a change in access
time, or that that's the most important factor. With both SRAM and
DRAM, I would think that the biggest problem would be increasing
leakage currents in the memory cells (or other gain-reducing
phenomena), increasing the soft error rates independent of access
time.
> As to what memory test is being "talked about", the answer is
> that there was no specification given. Just someone who wants
> some "memory test" programs, whatever that means.
Not true! The original request was very specifically for a POST-like
test that would go into spare space in a boot ROM. My initial post
on this thread outlined some techniques that make a reasonable
tradeoff among space, speed and fault coverage for that type of
application.
-- Dave Tweed
mdnt...@aol.com
I intend to use sufficiently fast RAM, or worst case, to add an M1 wait
state, to address the Z80 / Ram speed issues.
I wish to thank everyone who has replied... even Dr. "Johnson".. but
especially Allison, John G., and David T.. for their input. I have a
good feel for what's needed now, and will post here whatever code I end
up implementing so as to share with the group.
~ J
Lee Hart
> I tend to agree with David on the usefulness of having a POST, the
> functional core concept, and the incremental adding of tested hardware
> to this core until the system is fully up. That's exactly what I'm
> trying to do.
>
> I am running an Imsai front panel... but that's of no efficient use
> when trying to ascertain whether all my RAM chips are good upon
> startup.
>
> I have managed thus far to locate the source code to a Heath H17 ROM
> -- which has a memory test in it.
If you have the Heath documentation, look for a tiny little memory test
program they provided with the H8's and H89's. It's a RAM test program
so short that you can key it into your front panel or monitor. The test
routine moves itself up 1 byte, and executes itself. Thus it "walks" to
the top of RAM, outputs something to indicate success (lights a front
panel light, beeps the terminal), and repeats from 0.
It's not a very thorough test, but it does catch one kind of error
peculiar to the Z80. The Z80 requires the shortest memory access time
for an instruction fetch; so if all you do are data reads and writes,
you will miss memory that is good but too slow to execute a program
from.
> The rom-based PC Bios was revolutionary in how it abstracted the
> hardware from the OS...
Err... weren't there already a huge number of machines that did this?
And... just like all the other computers, people soon found that the ROM
BIOS was limited and buggy, and so loaded their own drivers to replace
it.
--
Ring the bells that still can ring
Forget the perfect offering
There is a crack in everything
That's how the light gets in -- Leonard Cohen
--
Lee A. Hart, 814 8th Ave N, Sartell MN 56377, leeahart_at_earthlink.net