f



wordstar & mbasic wont run

I hope that someone here will know the answer.
I have been changing my boot-rom recently to allow a different combination of compact flash and floppy disks.
I now find that everything works as it should but when I run either Wordstar or Mbasic the computer jumps back to command prompt.
I can use Newsweep PIP etc. All other software is OK as far as I can tell but I think that Wordstar takes over part of BDOS and maybe Mbasic does also, or at least they seem to work in a different way to other software.

The boot-rom loads BIOS into RAM switches off the EPROM then loads CCP + BDOS from Track 0 sets up zero page and jumps to CCP
At present I cannot understand why it would work with my previous boot-rom but not now.

I am using CP/M 2.2 56K
Any help appreciated. Thanks, Alan
0
Alan
9/18/2016 10:50:04 AM
comp.os.cpm 3422 articles. 0 followers. Post Follow

22 Replies
329 Views

Similar Articles

[PageSpeed] 59

First things first - find a memory and CPU test programs and test them.

Get fresh copies of mbasic and wordstar.

One or the other should be bad.

The fact that small programs run just tells you RAM is likely to be good both high and low.

Plus you could just have corrupted programs.

When you hear the sounds of hoof beats think horses not zebras.  There are two basic possibilities - Hardware or software.  Reloading fresh software eliminates one possibility.

A hardware/software issue could be in the BIOS - did you write your own?  It could be a deblocking issue.

Hardware can be CPU, RAM, or disk controller.

It is easiest to load diagnostics to start with, then refresh programs, then let is know if that helped or not.


Randy
0
randy482
9/18/2016 5:04:16 PM
On Sunday, September 18, 2016 at 6:04:17 PM UTC+1, rand...@hotmail.com wrote:
> First things first - find a memory and CPU test programs and test them.
> 
> Get fresh copies of mbasic and wordstar.
> 
> One or the other should be bad.
> 
> The fact that small programs run just tells you RAM is likely to be good both high and low.
> 
> Plus you could just have corrupted programs.
> 
> When you hear the sounds of hoof beats think horses not zebras.  There are two basic possibilities - Hardware or software.  Reloading fresh software eliminates one possibility.
> 
> A hardware/software issue could be in the BIOS - did you write your own?  It could be a deblocking issue.
> 
> Hardware can be CPU, RAM, or disk controller.
> 
> It is easiest to load diagnostics to start with, then refresh programs, then let is know if that helped or not.
> 
> 
> Randy

Hi Thanks for your reply. If I replace the boot-rom with the old one (which just boots up with 2 floppy disks A: & B:) then Wordstar and Mbasic run fine.

When I use the new boot-rom, which uses the compact flash to warm boot, then the problem occurs. As far as I can see it is the same CCP + BDOS but the BIOS is different to include the compact flash.

But as all other programs run OK I thought that maybe there was something special about Wordstar & Mbasic.

Alan
0
Alan
9/18/2016 6:24:31 PM
On Sunday, September 18, 2016 at 1:24:32 PM UTC-5, Alan Paton wrote:
> On Sunday, September 18, 2016 at 6:04:17 PM UTC+1, rand...@hotmail.com wrote:
> > First things first - find a memory and CPU test programs and test them.
> > 
> > Get fresh copies of mbasic and wordstar.
> > 
> > One or the other should be bad.
> > 
> > The fact that small programs run just tells you RAM is likely to be good both high and low.
> > 
> > Plus you could just have corrupted programs.
> > 
> > When you hear the sounds of hoof beats think horses not zebras.  There are two basic possibilities - Hardware or software.  Reloading fresh software eliminates one possibility.
> > 
> > A hardware/software issue could be in the BIOS - did you write your own?  It could be a deblocking issue.
> > 
> > Hardware can be CPU, RAM, or disk controller.
> > 
> > It is easiest to load diagnostics to start with, then refresh programs, then let is know if that helped or not.
> > 
> > 
> > Randy
> 
> Hi Thanks for your reply. If I replace the boot-rom with the old one (which just boots up with 2 floppy disks A: & B:) then Wordstar and Mbasic run fine.
> 
> When I use the new boot-rom, which uses the compact flash to warm boot, then the problem occurs. As far as I can see it is the same CCP + BDOS but the BIOS is different to include the compact flash.
> 
> But as all other programs run OK I thought that maybe there was something special about Wordstar & Mbasic.
> 
> Alan

No


Randy
0
randy482
9/18/2016 6:34:38 PM
The different boot rom is what probably did it.

WS needs to be installed when it's moved from one computer to another.

If you just copy it onto a disk, and try to move it onto a different hard drive (or floppy drive) that belongs with another computer, it will not run correctly.

Same thing happens with New Word and DBase II.
0
mike
9/19/2016 9:48:44 AM
On Monday, September 19, 2016 at 4:48:51 AM UTC-5, mike.d...@gmail.com wrote:
> The different boot rom is what probably did it.
> 
> WS needs to be installed when it's moved from one computer to another.
> 
> If you just copy it onto a disk, and try to move it onto a different hard drive (or floppy drive) that belongs with another computer, it will not run correctly.
> 
> Same thing happens with New Word and DBase II.

No it doesn't not for any of them.


Randy
0
randy482
9/19/2016 10:04:01 AM
Alan wrote:
> ...when I run either Wordstar or Mbasic the computer jumps back to command prompt...
> ...Same thing happens with New Word and DBase II...

I don't know what the problem is but perhaps there is a clue in the types of programs that run with no problem and the type of programs (4) you've discovered do not run.

It appears that simple programs that load into the TPA and run, cause no problems.

However, programs that load and must make access to external files on the floppy or floppies, appear to be the ones that fail.

Find out what they must do *differently* and you may find that they use part of the BIOS that has a bug... or part of the BDOS that is perhaps not completely loaded into memory.

One thing you could quickly check is the contents of the beginning and end of the BIOS and BDOS blocks loaded by your boot loader and verify its all there in memory. You might have to paint memory before the boot loader runs to see any untouched memory where critical CP/M code *should* be.

Otherwise just note the start and end contents of those blocks when you boot from the original floppy and make sure they're the same with your new boot-loader.

It couldn't hurt to look at the page zero block too (0000h-00FFh).

Good luck.

JDallas
0
9/25/2016 11:08:32 PM
On Monday, September 26, 2016 at 12:08:37 AM UTC+1, Jay_in_Dallas wrote:
> Alan wrote:
> > ...when I run either Wordstar or Mbasic the computer jumps back to comm=
and prompt...
> > ...Same thing happens with New Word and DBase II...
>=20
> I don't know what the problem is but perhaps there is a clue in the types=
 of programs that run with no problem and the type of programs (4) you've d=
iscovered do not run.
>=20
> It appears that simple programs that load into the TPA and run, cause no =
problems.
>=20
> However, programs that load and must make access to external files on the=
 floppy or floppies, appear to be the ones that fail.
>=20
> Find out what they must do *differently* and you may find that they use p=
art of the BIOS that has a bug... or part of the BDOS that is perhaps not c=
ompletely loaded into memory.
>=20
> One thing you could quickly check is the contents of the beginning and en=
d of the BIOS and BDOS blocks loaded by your boot loader and verify its all=
 there in memory. You might have to paint memory before the boot loader run=
s to see any untouched memory where critical CP/M code *should* be.
>=20
> Otherwise just note the start and end contents of those blocks when you b=
oot from the original floppy and make sure they're the same with your new b=
oot-loader.
>=20
> It couldn't hurt to look at the page zero block too (0000h-00FFh).
>=20
> Good luck.
>=20
> JDallas

Thanks for you suggestions - it could be any of the above. I have not reall=
y narrowed the problem down enough, also as I am using Floppy Disks and Com=
pact Flash it complicates the BIOS more.

To simplify the process I will just get the Compact Flash working first the=
n add the Floppy's when that is sorted.

Thanks, Alan
0
Alan
9/26/2016 9:12:49 PM
> I can use Newsweep PIP etc. All other software is OK as far as I can tell but I think that Wordstar takes over part of BDOS and maybe Mbasic does also, or at least they seem to work in a different way to other software.

Maybe your new BIOS is bigger than your old one, and when big programs think they're just overwriting the CCP to gain extra space, they also inadvertently gnaw at the bigger BIOS? 

The solution would be to sysgen a new version of CP/M adapted to the bigger BIOS.

The test case would be Turbo Pascal - does that show the same problem?

Regards,

Oscar.
0
vermeulen
9/26/2016 10:02:03 PM
Alan wrote:
> ...The boot-rom loads BIOS into RAM,
> switches off the EPROM, then loads 
> CCP + BDOS from Track 0,
> sets up zero page and jumps to CCP...

Your original floppy version was set up to have enough space above the CCP and BDOS, to properly place the BIOS next (above it), and reserve any Ram space it needs for variables or buffers in remaining memory.

It may be that your BIOS ran longer as it incorporated the CF media and thus encroached into that reserved ram block. While page zero has some RAM space that is used, including a 128byte buffer, I've seen buffers added after the BIOS in a few systems I've had over the years. Maybe the BIOS is still pointing to a big buffer for sectors there, that now has elongated BIOS loaded there. In this scenario, the first time a 256+ size sector is loaded in that reserved buffer, part of your BIOS is overwritten.

I assume you have the original BIOS source code for your system, you could start by looking at reserved space there. Maybe when the more sophisticated programs run, they're overwriting part of your BIOS.

***
Maybe you could tell us more details about your setup so we could converge upon the actual problem instead of guessing and possible scenarios.

For example, did your new BIOS fit in the same space as before (respecting any reserved ram needed)? If it were longer, it could have overwritten reserved space and that part of the BIOS gets clobbered later. The solution would be to either make the BIOS more tightly written or make a new CP/M size (that will relocate the CCP and BDOS to lower addresses and likewise begin the BIOS as a lower address.

One trick you could use, as I believe the Osborne did, is hide some of your code (BIOS) in the shadow Eprom. When its needed, it turns on the shadow Eprom and runs a little of it, then returns to the BIOS. Negatives are that the shadow Eprom typically runs slower with wait states, and if your shadow Eprom is also in high memory like your BIOS, you have to make a *BRIDGE* back so that the shadow Eprom disappears and the micro is still running code that hasn't disappeared, and it gets you back to the BIOS to clean things up and return.

Example bridge: Given the shadow Eprom and the BIOS are in the same address area; i.e. they don't map it at the same time. Use the 128byte buffer in page zero to copy a snippet of code to switch between the BIOS and shadow Eprom and jump to the next intended address in either. Later the BIOS can clean up the page Zero buffer, but it may not be necessary, but couldn't hurt.

JDallas
0
9/27/2016 10:07:01 PM
Another thing you can do *if* you have to bridge between the BIOS and shadow Eprom to maintain your 56K CP/M size:

Look at the BIOS for things that are *seldom* used and put those in the shadow Eprom.
It will have less affect on performance since so little runtime will be using the wait stated shadow Eprom.

Its better to keep the stuff you use a lot, like your User and Media interface, running in faster Ram instead.

I think in 2014 I wrote some stuff here about how it would have been better if CP/M had adopted a Ram banking approach in high memory to make very big TPAs. Of course, it would have required computer makers of the day to support that design; probably wouldn't have interested thm, considering Ram pricing back then.

JDallas
0
9/27/2016 10:27:28 PM
On Tuesday, September 27, 2016 at 11:27:27 PM UTC+1, Jay_in_Dallas wrote:
> Another thing you can do *if* you have to bridge between the BIOS and sha=
dow Eprom to maintain your 56K CP/M size:
>=20
> Look at the BIOS for things that are *seldom* used and put those in the s=
hadow Eprom.
> It will have less affect on performance since so little runtime will be u=
sing the wait stated shadow Eprom.
>=20
> Its better to keep the stuff you use a lot, like your User and Media inte=
rface, running in faster Ram instead.
>=20
> I think in 2014 I wrote some stuff here about how it would have been bett=
er if CP/M had adopted a Ram banking approach in high memory to make very b=
ig TPAs. Of course, it would have required computer makers of the day to su=
pport that design; probably wouldn't have interested thm, considering Ram p=
ricing back then.
>=20
> JDallas

Thanks for the interesting points.
The memory map I was using (and can still use) is 56K CP/M with the CCP at =
address BE00H - the BDOS at C600H - the BIOS at D400H and then an extended =
BIOS for compact flash at E000 to EFFFH.
The VDU occupies F000 to FFFF (2K)

Now I am writing a new BIOS, for Compact flash drive only, at D400-DFFFH
It is almost? working in that it seems to warm boot OK - The CCP and BDOS a=
re loaded into the correct locations from Track 0 on the CF drive, but when=
 it jumps to the CCP at BE00 the computer locks up.

It could be entering a loop where it keeps warm booting - I haven't confirm=
ed this yet.

Alan
0
Alan
10/8/2016 10:40:20 AM
Alan wrote:
> ...The VDU occupies F000 to FFFF (2K)...

That might be a typo for (4K) but it couldn't hurt to check your CP/M K-numbers and hex address blocks.

Its easy to get the Decimal+K numbers like 64K skewed with the hex address blocks.

I always think back to my 8K static ram S-100 cards with 8K being like E000h-FFFFh, C000h-DFFFh address blocks. 64K divided by 8K blocks means there a 8 blocks. For 0000h-FFFFh address space they would go 0000h-1FFFh, 2000h-3FFFh,4000h-5FFFh etc.

Maybe... if those numbers are mangled, as they're easy to do, generating a new CP/M for the Compact Flash, might have CP/M thinking its ok to load those bigger program *overwriting* CCP and some of the BDOS because the numbers are wrong.

Easy was to check that is to look at the CCP/BDOS/BIOS etc before loading the programs, and then looking to see if they were overwritten.

JDallas
0
10/10/2016 2:27:19 AM
Given:
> ...I am using CP/M 2.2 56K...
> @ F000-FFFFh :: VDU (4K @60K) Video reserved ram
> @ E000-EFFFh :: CFBIOS (4K @56K) compact flash drivers, extended bios
> @56K: CP/M 2.2 Standard Below
> @ D400-DFFFh :: BIOS (3K)
> @ C600-D3FFh :: BDOS (3.5K)
> @ BE00-C5FFh :: CCP (2K)

I have the CP/M manuals for CP/M 2 and CP/M 2.2 from my days at SD Systems. Your addresses above for the BIOS/BDOS/CCP appear to be too small. The CP/M 2.2 Alteration Guide (c) 1979, page 2 includes an example for 56K: CP/M:
bias = 56K - (20K) = 36K = 9000h where 20K is the standard distribution version of CP/M 2.2 which may change under second level system generation.

Bottom line 20K for CP/M is about 9000-DFFFh so your memory blocks for loading the CCP/BDOS/BIOS from the floppy image, appear to be incomplete.

That suggests the problem is in the loader - the block loads are wrong by destination address and length.

JDallas
0
10/10/2016 5:34:30 AM
On Monday, October 10, 2016 at 6:34:33 AM UTC+1, Jay_in_Dallas wrote:
> Given:
> > ...I am using CP/M 2.2 56K...
> > @ F000-FFFFh :: VDU (4K @60K) Video reserved ram
> > @ E000-EFFFh :: CFBIOS (4K @56K) compact flash drivers, extended bios
> > @56K: CP/M 2.2 Standard Below
> > @ D400-DFFFh :: BIOS (3K)
> > @ C600-D3FFh :: BDOS (3.5K)
> > @ BE00-C5FFh :: CCP (2K)
> 
> I have the CP/M manuals for CP/M 2 and CP/M 2.2 from my days at SD Systems. Your addresses above for the BIOS/BDOS/CCP appear to be too small. The CP/M 2.2 Alteration Guide (c) 1979, page 2 includes an example for 56K: CP/M:
> bias = 56K - (20K) = 36K = 9000h where 20K is the standard distribution version of CP/M 2.2 which may change under second level system generation.
> 
> Bottom line 20K for CP/M is about 9000-DFFFh so your memory blocks for loading the CCP/BDOS/BIOS from the floppy image, appear to be incomplete.
> 
> That suggests the problem is in the loader - the block loads are wrong by destination address and length.
> 
> JDallas

Thanks for your reply, I have the manuals (and I have looked at them).
 I got the VDU size wrong because the VDU display does occupy 2K but there is also 2K of programmable graphics.

The CCP + BDOS are fixed sizes (2K + 3.5K) but I thought that the BIOS could be any size depending on the system.
The CP/M system I am using does run OK at these addresses if I am using only floppy disks.
0
Alan
10/10/2016 3:16:28 PM
Yeah, I just looked at the memory map size of some CP/M installations and it about 10K in size. Perhaps the alteration guide uses the 20K figure just to make sure that resident CP/M and the basic commands that load from floppy into available TPA require at least a total ram of 20K to function.

That makes some sense. The locations of the CCP and BDOS would be closer to what you have.

JDallas
0
10/10/2016 8:18:12 PM
JDallas wrote:
> Bottom line 20K for CP/M is about 9000-DFFFh

That was an error.

The 9000h was the *Bias* which if I recall was the delta added to relocate the CP/M code into higher memory than the standard 20K version on the disk, thereby taking advantage of the system ram available for larger TPAs.

So CP/M would start at its 20K version (minimum for CP/M 2.2) *PLUS* the 9000h to locate it up in the low B000h block for your 56K available ram (since your Compact Flash BIOS is dealt with separately at E000-EFFFh. Thus CP/M fits in the block from Bxxx-DFFFh.

JDallas
0
10/11/2016 12:55:11 AM
Reply: