RC2014 CP/M-IDE

[phillip.stevens]

For a long time, I've been looking at making a very cut down version of CP/M for the RC2014.

Able to work off the minimum set of cards and most importantly being able to load from ROM and from FATFS formatted IDE drives.

And now that I've reached a reflection point in my YAZ180 development,

I was finally able to move some of that CP/M work over to the RC2014.

All of the code and instructions are available on GitHub in the RC2014 Repository.

So here it is: The RC2014 CP/M-IDE.

It is based on just three cards, the Pageable ROM, 64kB RAM, and Ed's IDE Adaptor.

On the software side the ChaN FatFs, the z88dk, and the original DRI CCP/BDOS/BIOS sources were used as inputs.

[djrm]

Fantastic work Phillip, just what I wanted.

Kind regards, David.

[Spencer Owen]

I am very excited by this.  I've had one of Ed's and one of Piano Matt's IDE boards sitting here unpopulated for a little while now, so this is just the excuse I need to build them up :-)

Spencer

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/c8931120-0256-47bb-97dc-ecf7d35b9705%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ed Brindley]

No excuses now ;-)

Ordered the pageable ROM module so I can also test this!

Cheers,

Ed

[Stephan van Radecke]

Sounds great !

But are there plans to let it work with the "Dual Serial Module SIO/2" ?

(the ACIA is 'retired' :-) )

Thanks

Stephan

[phillip.stevens]

Hi Stephan,

 

But are there plans to let it work with the "Dual Serial Module SIO/2" ?

There is quite a bit of ROM space free still, so there is no reason that a SIO/2 driver couldn't be written, and provided as an alternative.

Such a thing needs to be added to z88dk RC2014 support code anyway.

The only practical issue is that I don't have a SIO/2 board, and currently there are no plans for purchase.

(I've just spent my hobby allowance on YAZ180 PCB stocks).

And, actually adding the optional SIO/2 board is orthogonal to the "concept" of this CP/M build.

Being to provide CP/M "with the minimum of cards, complexity, and expense".

So whilst it could/should happen. I wouldn't hold my breath.

(the ACIA is 'retired' :-) )

As long as Spencer continues to include the ACIA in the "RC2014 Classic" BoM, I wouldn't really consider it retired.

But, I'm happy to be told otherwise. :-)

Let us know how you get on with the current build, and I'll be happy to take feedback either here, or as a Github issue.

Cheers, Phillip

 

[djrm]

This is the first outing of my IDE board, I was thinking I would have to get a paged ram/rom board to run CP/M for the IDE disk but Philips version has made this not necessary now.

Luckily I had a home made 6850 / ESP8266 board ready to hook up, mine can be jumpered for 0x40/0x80.

I'm well pleased, it seems to have all 'just worked' :-) Thanks.

I'd call that a result, here are the photos to prove it.

I'm not sure how to use it yet, I've a bit of reading to do. 

David.

On Thursday, 22 March 2018 11:22:41 UTC, phillip.stevens wrote:

[phillip.stevens]

David,

 

This is the first outing of my IDE board, I was thinking I would have to get a paged ram/rom board to run CP/M for the IDE disk but Philips version has made this not necessary now.

Luckily I had a home made 6850 / ESP8266 board ready to hook up, mine can be jumpered for 0x40/0x80.

I'm well pleased, it seems to have all 'just worked' :-) Thanks.

Great to see the confirmation that it works for someone else too.

Software... you never know.

 

I'd call that a result, here are the photos to prove it.

I'm not sure how to use it yet, I've a bit of reading to do. 

To save a bit of reading, just unzip these files onto your IDE drive. They can take any 8.3 character names you prefer. The .cpm extension is just for convenience. That will get you a good simple but complete CP/M system drive including MSBASIC v5.29; Zork1 throug Zork3; the BBCBASIC interpreter; and MSBASIC v5.3 Compiler.

Also, I think the USER.CPM file contains an AES demonstration program that shows off the number crunching capabilities of Z80. You'll need to have the SH CCP running to access it though, because the name contains an underscore which is forbidden in normal DRI CCP. SH is exited by typing "-x". It takes a bit of reading to find that command.

That's quite a system you've got together... puts my little system to shame.

It is good to see that the IDE to CF adapter also works out of the box too.

All of the code and instructions are available on GitHub in the RC2014 Repository.

Cheers, Phillip 

[djrm]

I had loaded three disks on the first successful boot but hadn't noticed that the terminal was issuing cr/lf which triggers the limited directory listing problem - only one file ws being shown. setting the terminal to send CR only fixes this. I cant find the AES demo program, I'll get a bigger CF card and load the other images, II ned somewhere to keep my programs too. Below is a capture of a better boot sequence. Is there a way to automate the boot, something like autoexec.bat ? David.

RC2014 - CP/M Monitor
feilipu 2018

> help
RC2014 - CP/M IDE Monitor v0.1
The following functions are built in:
  cpm [file][][][] - initiate CP/M with up to 4 drive files
  md - [origin] - memory dump
  help - this is it
  exit - exit and halt
  ls [path] - directory listing
  mount [path][option] - mount a FAT file system
  ds [drive] - disk status
  dd [drive][sector] - disk dump, sector in hex

> mount 1

rc=0 FR_OK

> ls
D-HS- 2018/03/22 23:10         0  SYSTEM~1
----A 2018/02/23 21:05  16777216  SYS.CPM
----A 2017/11/01 00:01  16777216  USER.CPM
----A 2018/02/04 21:42  16777216  ZORK.CPM
   3 File(s),  50331648 bytes total
   1 Dir(s),   13586432 bytes free

> cpm sys.cpm user.cpm zork.cpm
Opening "sys.cpm" at LBA 189
Opening "user.cpm" at LBA 32957
Opening "zork.cpm" at LBA 65725
Initialised CP/M

A>dir a:
A: ASM      COM : DDT      COM : ED       COM : EXIT     COM
A: INFO     COM : LOAD     COM : LUA      COM : LU       COM
A: MAC      COM : MBASIC   COM : MLOAD    COM : MOVCPM   COM
A: PIP      COM : SH       COM : STAT     COM : SUBMIT   COM
A: LS       COM : SYSGEN   COM : TE       COM : UNARC    COM
A: UNCR     COM : USQ      COM : XSUB     COM : Z80ASM   COM
A: ZEXALL   COM : ZEXDOC   COM : ZSID     COM : ZTRAN    COM
A: CAL      COM : DUMP     COM : KERMIT   COM : SHSAVE   COM
A: SH       OVR : ERASE    SUB : FULLPRMP SUB : NORMPRMP SUB
A>dir b:
B: CPSKER   HEX : CPVGEN   HEX
A>dir c:
C: FILE_ID  DIZ : ZORK1    COM : ZORK1    DAT : ZORK2    COM
C: ZORK2    DAT : ZORK3    COM : ZORK3    DAT
A>sh

       MicroShell - Version 2.0 
Copyright(c)1982 New Generation Systems

A0% dir
A: ASM      COM : DDT      COM : ED       COM : EXIT     COM : INFO     COM 
A: LOAD     COM : LUA      COM : LU       COM : MAC      COM : MBASIC   COM 
A: MLOAD    COM : MOVCPM   COM : PIP      COM : SH       COM : STAT     COM 
A: SUBMIT   COM : LS       COM : SYSGEN   COM : TE       COM : UNARC    COM 
A: UNCR     COM : USQ      COM : XSUB     COM : Z80ASM   COM : ZEXALL   COM 
A: ZEXDOC   COM : ZSID     COM : ZTRAN    COM : CAL      COM : DUMP     COM 
A: KERMIT   COM : SHSAVE   COM : SH       OVR : ERASE    SUB : FULLPRMP SUB 
A: NORMPRMP SUB 

A0% 

[Phillip Stevens]

I had loaded three disks on the first successful boot but hadn't noticed that the terminal was issuing cr/lf which triggers the limited directory listing problem - only one file ws being shown. setting the terminal to send CR only fixes this.

Things I forgot to mention...

I can't find the AES demo program, I'll get a bigger CF card and load the other images.

I just pushed it up to Github. There are lots of CP/M applications. This one was just one I found, which was quite a "modern" application which was compiled for CP/M from HighTech C. I was going to convert it to z88dk, but still haven't done it.

 

I'll need somewhere to keep my programs too. Below is a capture of a better boot sequence. Is there a way to automate the boot, something like autoexec.bat ? David.

Good idea. I was leaving it very manual as for the past months I've been looking at bytes in memory, and trying to make things work. So a good user interface was the last thing on my mind.

I'd still want to keep the cpm [file][ ][ ][ ] command "manual", because this is where you get to choose which files are going to be the drives you select.

But the mount command could be sucked into ls for sure.

Try to use ls when you're running MicroShell as below. It is an advanced directory command.

ls doesn't, however, work properly when you're NOT running MicroShell. I haven't dug into why.

Cheers, Phillip

[phillip.stevens]

Is there a way to automate the boot, something like autoexec.bat ? David.

Good idea. I was leaving it very manual as for the past months I've been looking at bytes in memory, and trying to make things work. So a good user interface was the last thing on my mind.

Based on (the) user feedback (thanks David), I've simplified the CLI to incorporate the file system mount into the commonly used functions.

This means that if you already know the names of the CP/M drives (files) you want to load, then the boot sequence is just one command.

As below.

I hope that makes things a bit more comfortable.

Also fixed a few non-issues, that just make me feel happier.

The new HEX code to download and a README are in the Github Repository.

Enjoy,

Phillip

[djrm]

Hello Philip,

I've tried your new binary image, it works, thankyou.

Actually what I had in mind was the very thing you said you did not want to do, read a file with some monitor commands in it to initialise the system.

This would then allow the system to boot directly into cp/m if that is what you wanted. I'd imagine you could write a few lines in an offline editor.

Of course the disk would need to be mounted first to be able to do that.

I have a couple of questions regarding the i/o map, I would like to be able to add in some other cards, in particular another serial card.

I would no need o/s driver support initially but I can see it would be an advantage to be able to use aux: prn: or whatever.

I started to write a SIO2 driver for z88dk but gave up when I realised that the existing 6850 driver interrupt wasn't working properly.

I understand this problem has now been fixed to when I have time I should try again but it is heavy going understanding the z88dk system.

I think integration with eclipse could help here - it saw you have been looking into this yourself, how do you find it?

I tried to add my parallel input / output card but when I did that the system would not boot properly, this surprised me as I thought that the lower i/o space was unused.

Could you let me know please if there is anything in the software which accesses i/o memory apart from the Page, IDE, and UART registers?

I'm using a compact flash to IDE adaptor with a 512kB card which as all your disk image files on it. Initially I had the CF adaptor set to 3v3, in this state neither of the three lleds on the card (Power, Active, and Card detect) ever lit. I changed the jumper to 5V and now they all work as expected. The LED on Ed's IDE card flashed at the same time as the CF adaptor LED. However after a power cycle or reset the the IDE adaptor LEDS are all unlit and the LED on Ed's IDE adaptor is lit. This changes when the card is accessed by a ls command even though the card is mounted. (I think I read somewhere that the card is only initialised at first access even though it is mounter so that could partly explain this)

I mentioned that I am using my 6850 - ESP8266 card to view the console, I've mad a small modification to this to feed 5v onto the ESP8266 taken from the un-switched 5v input to the RC2014 back-plane. This allows me to power cycle the main board without loosing my wifi link to the console. I find I have to power cycle the system quite often, pressing the reset button does not always restore the system, I dont know why, it could be I am using a dodgy eprom or something, it doesnt always boot.

I have added a power up reset chip onto the Z80 board and a tantalum decoupling capacitor onto the back plane, I am using what I think is a good power supply. ESP8266s are a bit power hungry so that is another avenue to check on my system. I find a reset more likely to succeed if I exit cp/m first, I guess this is something to do with the page signal. If I dont do this then a power cycle is needed to regain control. sometimes a wait is needed too, i.e. power off for a minute.

There is a new component in my system, Ed's IDE board. I have removed the PiZero terminal card, Input/Output card, Sound card, CF CP/m card from my usual system. I wonder if there is an address line floating or something.

Next I'll be adding some of my own archive cp/m programs onto the template drives, to see what I can do with it. nothing spectacular is planned, I'm just curious to see how it is going to work.

Kind regards, David.

[phillip.stevens]

I've tried your new binary image, it works, thank you.

Great. I'm not planning on touching it now for a week or so, so the latest CPM-IDE HEX version should stand long enough to make it worth burning.

Today the Melbourne GP is at the end of my street, so there's another plan afoot.

Actually what I had in mind was the very thing you said you did not want to do, read a file with some monitor commands in it to initialise the system.

This would then allow the system to boot directly into cp/m if that is what you wanted. I'd imagine you could write a few lines in an offline editor.

Of course the disk would need to be mounted first to be able to do that.

Actually, it would be dead easy to do what you need, because of the way the shell is built.

Doing this kind of thing is the reason why I built the shell in C with z88dk and use ChaN FATFS for the disk management.

All that is needed is to read the disk for a file, let's call it CPM.BAT for argument's sake, and check that it has at least one valid file name in it.

I'd probably check CPM.BAT exists, and if so feed CPM.BAT directly into the tokeniser, and then we'd be good to go.

But, let's hold on that for a while (see below comments on future work).

I have a couple of questions regarding the i/o map, I would like to be able to add in some other cards, in particular another serial card.

I would no need o/s driver support initially but I can see it would be an advantage to be able to use aux: prn: or whatever. 

I started to write a SIO2 driver for z88dk but gave up when I realised that the existing 6850 driver interrupt wasn't working properly.

There will be a driver for the SIO2 for the z88dk and for this build. A benefactor has provided, and it is on its way.

Will take a while to get here, but stand by.

The reason that I'm keen to do it is the single USART version is has been nurfed down from what the bios can already do.

I built two physical ports support, with the IOBYTE support, already for YAZ180. So there is no issue to do it for RC2014 too.

I understand this problem has now been fixed to when I have time I should try again but it is heavy going understanding the z88dk system.

I think integration with eclipse could help here - it saw you have been looking into this yourself, how do you find it?

I've come to think of z88dk as a life partner - not some drunken weekend one night stand.

It can be complex, but that complexity rewards those who are committed to a deeper relationship.

There are so many neat tricks used in the CPM-IDE, based on z88dk capabilities.

I've not actually gotten Eclipse integration working. It would be nice to have, but I didn't get to it yet. So much else to do.

 

I tried to add my parallel input / output card but when I did that the system would not boot properly, this surprised me as I thought that the lower i/o space was unused.

Could you let me know please if there is anything in the software which accesses i/o memory apart from the Page, IDE, and UART registers?

There is a long email thread between Ed and I on this topic. The essence of which is "How do I hold my tongue to make your IDE card work...?" "Never mind, it just works."

The DIOv1 card is not supported. The addressing is all over the place, as Spencer didn't design it as a "product". Neither is the Joystick card supported.

Ed has a list of conflict issues somewhere. I don't have any additional cards to comment fully.

I'm using a compact flash to IDE adaptor with a 512kB card which as all your disk image files on it. Initially I had the CF adaptor set to 3v3, in this state neither of the three leds on the card (Power, Active, and Card detect) ever lit. I changed the jumper to 5V and now they all work as expected. The LED on Ed's IDE card flashed at the same time as the CF adaptor LED. However after a power cycle or reset the the IDE adaptor LEDS are all unlit and the LED on Ed's IDE adaptor is lit. This changes when the card is accessed by a ls command even though the card is mounted. (I think I read somewhere that the card is only initialised at first access even though it is mounter so that could partly explain this)

I mentioned that I am using my 6850 - ESP8266 card to view the console, I've mad a small modification to this to feed 5v onto the ESP8266 taken from the un-switched 5v input to the RC2014 back-plane. This allows me to power cycle the main board without loosing my wifi link to the console. I find I have to power cycle the system quite often, pressing the reset button does not always restore the system, I don't know why, it could be I am using a dodgy eprom or something, it doesn't always boot.

I have added a power up reset chip onto the Z80 board and a tantalum decoupling capacitor onto the back plane, I am using what I think is a good power supply. ESP8266s are a bit power hungry so that is another avenue to check on my system. I find a reset more likely to succeed if I exit cp/m first, I guess this is something to do with the page signal. If I dont do this then a power cycle is needed to regain control. sometimes a wait is needed too, i.e. power off for a minute.

The reason it doesn't boot is that there is a "canary" that I use to see whether the bios exists. With the extra capacitance on the backplane there is enough residual power to keep some of the RAM contents and (at least the) the "canary" intact. So things can go wrong from there. I know this because I did the same thing with extra 500uF of power supply capacitance. Takes about 20 seconds to discharge for me.

Next I'll be adding some of my own archive cp/m programs onto the template drives, to see what I can do with it. nothing spectacular is planned, I'm just curious to see how it is going to work.

Good luck,

Phillip 

[phillip.stevens]

I've tried your new binary image, it works, thank you.

Great. I'm not planning on touching it now for a week or so, so the latest CPM-IDE HEX version should stand long enough to make it worth burning.

In the process of building the SIO/2 drivers, I identified a bug in my ACIA driver implementation, where when many characters are being driven into the Tx buffer, the input pointer and buffer count would get out of sync. So I fixed that and uploaded a new HEX file.

The effect was only obvious when using the advanced directory command LS, or when using the modern text editor TE, both found in the system disk, where they would lose characters and get out of sync. Fixed now.

 

There will be a driver for the SIO/2 for the z88dk and for this build. A benefactor has provided, and it is on its way.

Will take a while to get here, but stand by.

The SIO/2 drivers are progressing, but the SIO is proving to be a difficult beast to tame. It seemingly behaves randomly.

Also, most of the implementations I am referencing don't agree with the datasheet in important details, so it is difficult to know who to believe.

Anyway it doesn't matter because solving issues is part of the fun.

[phillip.stevens]

I've tried your new binary image, it works, thank you.

Great. I'm not planning on touching it now for a week or so, so the latest CPM-IDE HEX version should stand long enough to make it worth burning.

The SIO/2 drivers are progressing, but the SIO is proving to be a difficult beast to tame. It seemingly behaves randomly.

Also, most of the implementations I am referencing don't agree with the datasheet in important details, so it is difficult to know who to believe.

Anyway it doesn't matter because solving issues is part of the fun.

Now that the new SIO/2 drivers have been pulled into Z88DK and are part of the new -subtype=sio option, I've also created a new CP/M-IDE SIO build.

This version of CP/M-IDE doesn't strictly comply with the original intention; to get CP/M running as fast as possible on the minimum RC2014 hardware.

But it doesn't stray too far from the intention and, since CP/M needs to have at least two physical ports to work well, adding SIO support was a natural thing to do.

To write the SIO/2 drivers, I've gone back to the original datasheets and the Leventhal book from 1983 to see what they had to offer. For me it was a great learning experience with Z80 IM2 mode, and working for the first time with a Zilog peripheral device that could steer its interrupts using the IM2 interrupt response process. I always find it enlightening when I actually write the code, because the words in the datasheets don't mean that much to me until I have to study and "know" each bit.

Anyway, it is done now, and there are now two versions of CP/M-IDE. One for the ACIA, and the other for the SIO/2.

In response to that question, "can I have both?".

The answer is yes, of course you can have both, but there are caveats that mean that I'll probably never build it.

The ACIA can't work in IM2 mode, so you'd have to load the address bus to get a fake IM2 address provided in response to ACIA interrupts.

Also, putting another set of serial drivers and transmit and receive buffers into the CP/M bios would consume yet more of the free application memory.

In summary, the Z88DK already allows both drivers to co-exist, and can support writing the IM2 table required to get both devices working, and anyone can clone the repository, and go for it.

Some build and usage notes.

For the SIO, to get to the shell prompt > after restarting the RC2014 use a colon : not a space  .

Why? Because I can't see a space, and I like to know that I'm actually sending a character.

The SIO Port B is configured with no remote echo. That is usual for TTY interfaces, that might waste bandwidth by sending echo characters back. Use local echo.

The SIO Port A is configured with echo as normal. These options are just Z88DK input terminal configurations, that can be easily changed at build time.

DDT works with the SIO implementation, but it doesn't work with the ACIA version.

This is because of the use of the RST38 interrupt for IM1 mode. Other threads have covered this.

A lot of people seem to report troubles with Compact Flash cards in 8 bit mode.

Perhaps try using Ed's IDE card to drive the CF in PATA 16 bit mode?

It might take away some pain.

I hope this is a useful addition to the RC2014 CP/M options.

Building it was a great learning experience.

Cheers, Phillip

[djrm]

Hi Phillip, 

I had some time today to try the new SIO version of CP/M

the new build is working well for me on both SIO and ACIA cards. 

I'm preferring to use the SIO card now to make use of the two ports available.

The second port will be handy for Kermit file transfers, I've proved its working on on the TTY port.

I can send and receive files from my PC, I've been using the David Goodwin's windows gui version of Kermit from here: Kermit95

There are some brief instructions for using kermit here: Kermit example which I followed (except the second serial is TTY)

Here is a CP/M transcript of my initial test sessions:

One thing which did confuse me at the outset was the lack of any echo on either serial port, just the monitor sign on appears. After checking everything and even burning another eprom I eventually read the instructions and typed ':' and the system sprang into life. I never saw the ':' echoed on the terminal, whichever port I used.

At one point I thought my system was broken the 'canary' was holding onto something but it came back to life after tea.

It will be interesting to see if Ed's sound card will co-exist in this configuration.

All good clean fun, thanks for your efforts. David.

[phillip.stevens]

Hi David,

 

I had some time today to try the new SIO version of CP/M

the new build is working well for me on both SIO and ACIA cards. 

Very happy to hear it is working for you! :-)

 

I'm preferring to use the SIO card now to make use of the two ports available.

Yes. I'm also preferring the SIO too, simply because DDT works properly.

 

The second port will be handy for Kermit file transfers, I've proved its working on on the TTY port.

I can send and receive files from my PC, I've been using the David Goodwin's windows gui version of Kermit from here: Kermit95

There are some brief instructions for using kermit here: Kermit example which I followed (except the second serial is TTY).

I haven't tried to use Kermit in earnest yet, though I did put it on my sys.cpm drive (file) and played with it.

It seemed a bit clunky to use when there was only one port available, and there was the option to just write files directly onto the drive on my PC.

With two ports it will be much more convenient, and useful.

I must patch a ESP-01S onto the TTY port to try. Just need to use a 3V3 supply, as the I/O is 5V tolerant.

I have ESP-01S devices installed and working on my YAZ180 boards, but I haven't tried them on RC2014.

 

One thing which did confuse me at the outset was the lack of any echo on either serial port, just the monitor sign on appears. After checking everything and even burning another eprom I eventually read the instructions and typed ':' and the system sprang into life. I never saw the ':' echoed on the terminal, whichever port I used.

Yes, I'm probably a bit terse there. At one stage I was deleting strings to try to fit the FATFS write capability for the shell into the 32kB of ROM, but in the end it didn't fit and I didn't put any verbosity back into the shell. Might be appropriate to add some text back in.

 

At one point I thought my system was broken the 'canary' was holding onto something but it came back to life after tea.

You must added have a __LOT__ of capacitance on your backplane. I'm using the USB 5V to power my RC2014 normally, and I just have do like "1 mosquito 2 mosquito 3 mosquito" before I plug it back in, to ensure the RAM canary is dead.

 

It will be interesting to see if Ed's sound card will co-exist in this configuration.

Yes. I don't doubt that it will work. But we'll be relying on you to test it.

Enjoy the tunes (fingers crossed).

BTW. I put your picture of your machine on the RC2014 CP/M-IDE github readme. I hope that's ok.

Also based on your example, I've purchased some IDE to CF adapters, with little cables, to try using CF cards in my RC2014.

It should be more convenient than plugging my SSD IDE Drive into a USB caddy to write CP/M drives (FATFS files).

Though, on a price per GB basis, CF cards are basically a rip-off.

I make Compact Flash cards about 20x as expensive as SSD IDE drives.

What we pay for convenience.

Cheers, Phillip

[djrm]

Hi Phillip,

I was a bit hasty saying things were going well, although Kermit appeared to receive files properly on the RC2014, they never get saved onto the fie system. transfers to the PC are working ok. its a shame as the automatic file serving on the PC is going to be handy. is this version of Kermit usable on standard RC2014, I'll try it and see.

I have heard that ESP8266 i/o are 5 volt tolerant but I dont think that is the official line. I use level shifters in 5 volt applications. The simple board with 3v3 regulator and level shifters onboard I find quite handy, they can be bought for a small premium if you search around on ebay and aliexpress.

n.b I use a 47 uF tant bead capacitor on the pro backplane, perhaps a bleed resistor would help.

I shall not have time to dig around and see what the problems are until after tomorrow, Kind regards, David.

[phillip.stevens]

Hi David,

I was a bit hasty saying things were going well, although Kermit appeared to receive files properly on the RC2014, they never get saved onto the fie system. transfers to the PC are working ok. its a shame as the automatic file serving on the PC is going to be handy. is this version of Kermit usable on standard RC2014, I'll try it and see.

That had me worried, so I tested to see that the file system was actually working...

> PIP B:A_FILE.COM=A_FILE.COM

Works as expected. Deep breath.

I'll have to look into Kermit, and see what happens for me.

I remember compiling the CPSKER and CPVGEN pieces separately, and then using PIP to put them together.

But, since I've not actually used it (beyond checking that the program launched, and responded to commands, and exited) I can't really comment yet.

Cheers, Phillip

[Phillip Stevens]

One thing which did confuse me at the outset was the lack of any echo on either serial port, just the monitor sign on appears. 

After checking everything and even burning another eprom I eventually read the instructions and typed ':' and the system sprang into life.

Updated the UI a little, just to remind the user that a : is expected, for the SIO version.

And added a happy face, just because.

Cheers, Phillip

[phillip.stevens]

Now that the new SIO/2 drivers have been pulled into Z88DK and are part of the new -subtype=sio option, I've also created a new CP/M-IDE SIO build.

This version of CP/M-IDE doesn't strictly comply with the original intention; to get CP/M running as fast as possible on the minimum RC2014 hardware.

But it doesn't stray too far from the intention and, since CP/M needs to have at least two physical ports to work well, adding SIO support was a natural thing to do.

To write the SIO/2 drivers, I've gone back to the original datasheets and the Leventhal book from 1983 to see what they had to offer. For me it was a great learning experience with Z80 IM2 mode, and working for the first time with a Zilog peripheral device that could steer its interrupts using the IM2 interrupt response process. I always find it enlightening when I actually write the code, because the words in the datasheets don't mean that much to me until I have to study and "know" each bit.

Anyway, it is done now, and there are now two versions of CP/M-IDE. One for the ACIA, and the other for the SIO/2.

 

Also, now there is a Dr SM Baker SIO/2 build in the RC2014 Repository.

I don't have one of these boards, but since the only change is addressing the SIO/2, it should just work.

 

 Some build and usage notes.

For the SIO, to get to the shell prompt > after restarting the RC2014 use a colon : not a space  .

Why? Because I can't see a space, and I like to know that I'm actually sending a character.

The SIO Port B is configured with no remote echo. That is usual for TTY interfaces, that might waste bandwidth by sending echo characters back. Use local echo.

The SIO Port A is configured with echo as normal. These options are just Z88DK input terminal configurations, that can be easily changed at build time.

DDT works with the SIO implementation, but it doesn't work with the ACIA version.

This is because of the use of the RST38 interrupt for IM1 mode. Other threads have covered this.

A lot of people seem to report troubles with Compact Flash cards in 8 bit mode.

Perhaps try using Ed's IDE card to drive the CF in PATA 16 bit mode?

It might take away some pain.

There are a few notes about the things that need to be configured in z88dk to convert from Spencer's SIO/2 to Dr Baker's SIO/2 in the commit comment.

But, a diff of the two builds shows the few bytes that needed to change.

Happy to hear whether it works.

[Richard Deane]

Would your version of CP/M work with the RC2014 512KB ROM/RAM board as used by romwbw?

[phillip.stevens]

Would your version of CP/M work with the RC2014 512KB ROM/RAM board as used by romwbw?

This version of CP/M-IDE doesn't strictly comply with the original intention; to get CP/M running as fast as possible on the minimum RC2014 hardware. 

...there are now two versions of CP/M-IDE. One for the ACIA, and the other for the SIO/2.

Also, now there is a Dr SM Baker SIO/2 build in the RC2014 Repository.

Richard,

now that's an interesting question.

There's no reason why it would not be easy to support the 512kB ROM/RAM board. Except it is orthogonal to the original intention for this build, being to support CP/M on the minimum expense of hardware.

If you've got a 512kB ROM/RAM board, wouldn't you be better served with ROMWBW? There are a lot of additional features cooked into the requirement to have 512kB of ROM/RAM, that aren't easy (possible) to do in 32kB ROM / 64kB RAM.

I think that the support for FATFS formatted PATA drives / CF is the only functional advantage for CP/M-IDE. And while that is a compelling attribute for me, I'm not sure that it is a widely needed feature. Indeed if it were compelling, I'm sure it would have been done before now.

I'll have a look at the 512kB ROM/RAM board specs, and comment again soon.

Cheers, Phillip

[Richard Deane]

Thanks,

I'm still experimenting with all the RC2014 options, and  following jblang's z80ctrl closely.

My end goal is to get a CPM or compatible system that supports profile.sub or similar autoexec-like functionality (e.g. load rtc driver); command line recall and printing support (maybe via serial, or via raspberry pi with some direct pcb connection, where the pi can have all the necessary drivers and usb / networking). I'm trying to avoid purchasing an Epson dot matrix printer with rs232 port as I have laser and inkjet. I'd like to get a system capable of day-to-day word processing.

Of course it's good to have CP/Net for easy transfer to and from host files (having problems, maybe with size or data transfer quality via xmodem downloading z8e41.pkg to rc2014)

I like yaze-ag, myz80 and simh but looking for a real home-built physical equivalent. Yaze-ag and simh don't seem to support direct printing, only via host file. MyZ80 using Epson LQ for CPM and running DosPRN to translate to HP PCL works nicely but requires Windows and 32-bit only, and now with Windows 10 requires NTVDM to be configured.

I quite like RunCPM which works on my Teensy3.6, but printing support is only under development; AltairDuino I've not got working with SD card on an Arduino Due, and isn't supported on the Teensy with built-in SDcard - like the concept of some switches and display but happy for a modern lcd panel rather than all the necessary soldering (and inflexibility) of individual data and address leds.

So far the Z80ctrl seems a possibility when bugs ironed out as it has a range of boots available.

Richard

[phillip.stevens]

I had a think about how to avoid the bounce interrupt from the SIO Tx, originated by the final byte in the buffer, and fixed it for the two SIO builds. Had to leave interrupts disabled a little longer to maintain Tx buffer consistency, but overall it should be slightly faster at transmitting.

The new CP/M-IDE SIO builds are in the RC2014 repository.

Enjoy, Phillip

On Friday, 27 April 2018 12:43:50 UTC+10, phillip.stevens wrote:

Now that the new SIO/2 drivers have been pulled into Z88DK and are part of the new -subtype=sio option, I've also created a new CP/M-IDE SIO build.

This version of CP/M-IDE doesn't strictly comply with the original intention; to get CP/M running as fast as possible on the minimum RC2014 hardware. But it doesn't stray too far from the intention and, since CP/M needs to have at least two physical ports to work well, adding SIO support was a natural thing to do.

Anyway, it is done now, and there are now two versions of CP/M-IDE. One for the ACIA, and the other for the SIO/2.

 

Also, now there is a Dr SM Baker SIO/2 build in the RC2014 Repository.

I don't have one of these boards, but since the only change is addressing the SIO/2, it should just work.

 Some build and usage notes.

• For the SIO version, to get to the shell prompt > after restarting the RC2014 use a colon : not a space  . Why? Because I can't see a space, and I like to know that I'm actually sending a character.

• The SIO Port B is configured with no remote echo. That is usual for TTY interfaces, that might waste bandwidth by sending echo characters back. Use local echo. 
  
• The SIO Port A is configured with echo as normal. These options are just Z88DK input terminal configurations, that can be easily changed at build time.

[phillip.stevens]

Over the past few weeks I've been stalking an interesting (nasty) bug related to CP/M-IDE, CF cards, and the IDE interface.

The symptom only appears when using a CF card, and only when using the IDE interface. Basically the CP/M-IDE CCP is not properly restarted, once a command disk related command has been correctly completed, and the terminal just hangs after a CR. The command can be a complex PIP command, or simple CCP internal command like DIR.

B>A:PIP C:TEST.HEX=TEST.HEX

Successfully completes, (because the files are correctly copied from B: to C:) but then hangs when returning, for example.

But even a DIR following a successful disk related command fails.

It only happens when using the RC2014 IDE interface with a CF card. It does not happen when using same code on the same platform with a PATA drive.

It also doesn't happen using very similar CP/M code on YAZ180, with a similar IDE interface, and with a CF card. Whilst this is not a direct connection, the diskio routines are identical across the two platforms and I'm pretty sure that it is not the actual diskio or CP/M diskio that is at fault.

I've been adjusting a lot of minor issues over the past few weeks. But none of these minor fixes have caught the underlying problem.

It could be that the CCP is not being rewritten following a "large" command, i.e. a RAM toggle failure, but the failure following the DIR command seem to rule that out.

To be honest, I've no idea why it is failing.

Ed, Spencer, could you share your experience with CF cards on CP/M-IDE, please? Does it work for you?

Cheers, Phillip

On Tuesday, 8 May 2018 22:11:51 UTC+10, phillip.stevens wrote:

I had a think about how to avoid the bounce interrupt from the SIO Tx, originated by the final byte in the buffer, and fixed it for the two SIO builds.

[Spencer Owen]

I don't actually have a IDE to CF card adapter, so I don't think I'll be able to test this for you.  

I have both Eds and Matts IDE card, but only have regular (2.5" or 3.5") IDE drives for it, or I have my RC2014 Compact Flash Module with either regular CF cards or a 1" Microdrive.  

By the sounds of it, I'm not going to be affected by the bug that you're hunting :-(  But if there are any tests I can do with that combination of equipment, let me know.

Spencer 

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/be42a892-8cda-4d0b-bde2-1e0cb5c1e12b%40googlegroups.com.

[Bill Shen]

I read this topic when I initially joined RC2014 forum in March.  I didn't understand the discussion at the time.  I'm a little bit smarter now so my understanding of CP/M-IDE is that it runs CP/M 2.2 from FATFS formated CF.  The big advantage is that files can be easily transferred from PC or other desktops.  There are other improvement like interrupt driven serial port.

I have ported CP/M2.2 and CP/M3 (non banked version only--banked version is too hard for me) to Z280RC, but FATFS and interrupt driven serial ports are big attractions.  There is also Z88DK connection lurking in the background that I don't yet understand.  Since Z280RC is single module, it certainly meets the "minimal set" approach.  So I like to know what's the process for porting CP/M-IDE to Z280RC? 

* The Z280RC has 16-bit-wide IDE that's bus connected so there are no 82C55 interface to worry about.  It does require Z280 specific IN and OUT instructions that works with 16-bit I/O.
* Z280 has an additional interrupt mode, Mode 3, which is the prefer mode of operation for Z280.  I'm in the process of getting smart about it.
* Track 0 of CF is the "ROM" for Z280RC.  CP/M 2.2, 3, monitors (including SC Monitor) are located there.  More importantly, the cold bootstrap code is located in the CF's boot sector.  I can relocate the ROM codes, but cold bootstrap is hardwired to the boot sector.  It is unclear to me whether the Z280RC's cold bootstrap code can coexist with FATFS.  I do know that Z280RC bootstrap code is about 160 bytes and does not intrude on the Partition entries of Master Boot Record at 0x1BE-0x1EE, if that helps. 
*  What role does Z88DK plays in CP/M-IDE?  In following up to your suggestion about raise an issue for 'Z280 support" with Z88DK I started reading their discussions.  It is way over my head!  I'm just the little guy trying to use some features of the high level languages, if they start to ask me questions about what I need, I probably won't even understand their questions.  So can I skip Z88DK for another day?

  Bill

PS, comments about your latest issue with CCP not restarting properly:
1.  Have you tried different CF disks and the problem gets better or worst?
2.  Have you tried PIP with verify, e.g. A:PIP C:=*.*[V]

On Thursday, March 22, 2018 at 5:22:41 AM UTC-6, phillip.stevens wrote:

For a long time, I've been looking at making a very cut down version of CP/M for the RC2014.

Able to work off the minimum set of cards and most importantly being able to load from ROM and from FATFS formatted IDE drives.

And now that I've reached a reflection point in my YAZ180 development,

I was finally able to move some of that CP/M work over to the RC2014.

All of the code and instructions are available on GitHub in the RC2014 Repository.

[phillip.stevens]

Bill,

 

I read this topic when I initially joined RC2014 forum in March.  I didn't understand the discussion at the time.  I'm a little bit smarter now so my understanding of CP/M-IDE is that it runs CP/M 2.2 from FATFS formated CF.  The big advantage is that files can be easily transferred from PC or other desktops.  There are other improvement like interrupt driven serial port.

Yes, on both counts.

I've a CF (SD, and other cards) adapter installed in the 3.5" floppy port of my PC, and it is so easy to move files back and forward with that system. For a real PATA disk, I just use an old USB caddy to mount the drive. So FATFS formatting (and CP/M tools) is really the way to go.

Also interrupt driven serial receive is pretty much mandatory for a "slow" Z80. Interrupt driven transmit is really useful too, as per the mandelbrot discussion elsewhere.

 

I have ported CP/M2.2 and CP/M3 (non banked version only--banked version is too hard for me) to Z280RC, but FATFS and interrupt driven serial ports are big attractions.  There is also Z88DK connection lurking in the background that I don't yet understand.  Since Z280RC is single module, it certainly meets the "minimal set" approach.  So I like to know what's the process for porting CP/M-IDE to Z280RC? 

 

 The approach I took was to make the disks orthogonal, by putting storing the CCP/BDOS and BIOS code in ROM.

This means that all the disks are identical in format, so it doesn't matter where they're loaded. Specifically, there is no system disk with special tracks. So any disk can be disk A:. Also, small CF cards mean that the last disk is less than normal size, so it has to be treated specially. I avoided that issue too.

By using a large CF card or PATA drive, and locating as many CP/M drive files as needed on the drive, you only need one drive type, and it makes implementing the BIOS so much easier.

By limiting the number of active CP/M drives to 4, this means that only four allocation vector spaces need to be provided. For 16MB drives, the ALV space requirements are quite large. CP/M-IDE works by allowing the user to exit CP/M and "change disks" simply by restarting with different drive files nominated. Typically I'll have one system drive, one application drive (which changes depending on what I'm doing), and one or two user drives.

Original CP/M came with 4 drives too, so this idea is not novel. Actually, it is more original.

* The Z280RC has 16-bit-wide IDE that's bus connected so there are no 82C55 interface to worry about.  It does require Z280 specific IN and OUT instructions that works with 16-bit I/O.
* Z280 has an additional interrupt mode, Mode 3, which is the prefer mode of operation for Z280.  I'm in the process of getting smart about it.

The ChaN FatFS code is written to be independent of the underlying disk I/O code. There are I/O implementations for many different block and linear devices. It should be relatively easy to convert the code written for CP/M-IDE diskio for Z280. The logic is identical. It is only the mechanism of moving the data and address lines at the right time that matters. For the 82C55 it was a little complicated by the fact that two ports have to be coordinated to generate a 16 bit transfer. For the Z280 this will be simplified by 16 bit I/O.

This is the code to read a byte, and to write a byte. The only other code needed is to read and write a sector. Everything else builds on these four routines. For those four routines you can use your special instructions, to the specific addresses you need. Other than that it will be just normal Z80 code, that you can borrow directly.

If you know the LBA locations of the origins of the CP/M drive files, you don't even need to use FatFS.

It relies on the CP/M drive files being contiguous, and just reads/writes based on the offset from the origin LBA address provided into a static location in the BIOS on boot.

 

* Track 0 of CF is the "ROM" for Z280RC.  CP/M 2.2, 3, monitors (including SC Monitor) are located there.  More importantly, the cold bootstrap code is located in the CF's boot sector.  I can relocate the ROM codes, but cold bootstrap is hardwired to the boot sector.  It is unclear to me whether the Z280RC's cold bootstrap code can coexist with FATFS.  I do know that Z280RC bootstrap code is about 160 bytes and does not intrude on the Partition entries of Master Boot Record at 0x1BE-0x1EE, if that helps. 

IMHO, it makes more sense (with the ROM that we have available, that they didn't have in the 70's), to put the CP/M CCP/BDOS and BIOS into ROM. The advantage of separating the boot code from the mass storage is clear. Particularly the ability to have orthogonal disk sizing.

The boot / warm boot process for CP/M-IDE is like this.

1. preamble code that loads the CCP/BDOS.

2. check whether BIOS is enabled, and if it is because we have a warm boot situation (RST0 happened), jump into CP/M.

3. preamble code loads the BIOS (containing serial drivers, and IDE drivers for use by CP/M).

4. launch the shell, to allow the CP/M to be started.

5. in the shell, initialise CP/M drive LBA locations, and pass them to CP/M as it boots.

*  What role does Z88DK plays in CP/M-IDE?  In following up to your suggestion about raise an issue for 'Z280 support" with Z88DK I started reading their discussions.  It is way over my head!  I'm just the little guy trying to use some features of the high level languages, if they start to ask me questions about what I need, I probably won't even understand their questions.  So can I skip Z88DK for another day?

Don't worry about that. AA (@aralbrec) @suborb, and the rest of the Z88DK team are some of the nicest onlline people I've met (current company excluded of course ;-). There is a lot of discussion currently about moving from separate classic libraries to integrate them with the new libraries, and specific support of many old platforms. Which is great, but also over my head too. Dive in!

z88dk is used to coordinate all of the pieces. The respective compilation models provide defaults for a Page 0, preamble, locating "data" sections, creating "bss" sections, establishing the C library i/o streams, heap, and other housekeeping that C CRTs normally keep hidden under the covers for you.

I use the z88dk-lib library functions to separately compile the FatFS code and then install it as a third party library into z88dk. The FatFS code is not polite, in that all the functions are in one file, and the z88dk compilers are not smart enough to separate functions. This means that all the functions in a single file are linked into a build, whether or not they are used. z88dk normally has one function per file, so that this issue is worked around. gcc compiler can do --function-sections and --data-sections to avoid this issue for its linker. So, best to keep it separate and configure it to suit exactly the application in hand.

Don't be concerned about the apparent complexity of z88dk. All of the pieces that you need to worry about are included under the specific platform RC2014, or the target folder it is contained within. 

All the C library components otherwise come along for free, and are why you use z88dk. You don't need to re-invent wheels with library code, because they have done libraries more expertly and comprehensively than you could ever think of doing.

 

PS, comments about your latest issue with CCP not restarting properly:
1.  Have you tried different CF disks and the problem gets better or worst?

No, I only have 2x 1GB Verbatum drives. I was hoping that Ed (who made the IDE interface) or Spencer could provide some reference with other cards. I'm still gestating other ideas, but grasping at straws now. Currently thinking that somehow the LBA storage locations are being overwritten, so the next drive access fails... straws...

 

2.  Have you tried PIP with verify, e.g. A:PIP C:=*.*[V]

No. I will. But the PIP and any other command works successfully, and returns successfully. It is the NEXT command that fails to return. Which is why is is very odd, because for the CCP to provide a prompt following the first command, it must be present. But is is somehow damaged so that the following command (either internal CCP or unknown external) fails...

Good luck with building CP/M-Z280.

I think it shouldn't be too hard for you.

Cheers, Phillip

[phillip.stevens]

By the sounds of it, I'm not going to be affected by the bug that you're hunting :-(  But if there are any tests I can do with that combination of equipment, let me know.

Spencer 

On 30 May 2018 at 10:15, phillip.stevens wrote:

Over the past few weeks I've been stalking an interesting (nasty) bug related to CP/M-IDE, CF cards, and the IDE interface.

The symptom only appears when using a CF card, and only when using the IDE interface. Basically the CP/M-IDE CCP is not properly restarted, once a command disk related command has been correctly completed, and the terminal just hangs after a CR. The command can be a complex PIP command, or simple CCP internal command like DIR.

B>A:PIP C:TEST.HEX=TEST.HEX

Successfully completes, (because the files are correctly copied from B: to C:) but then hangs when returning, for example.

But even a DIR following a successful disk related command fails.

It only happens when using the RC2014 IDE interface with a CF card. It does not happen when using same code on the same platform with a PATA drive.

It could be that the CCP is not being rewritten following a "large" command, i.e. a RAM toggle failure, but the failure following the DIR command seem to rule that out.

To be honest, I've no idea why it is failing.

Ed, Spencer, could you share your experience with CF cards on CP/M-IDE, please? Does it work for you?

Got a sniff of an answer, but it may be only partially right.

I was using MLOAD v2.1 to create my binaries after using PIP to transfer them, which was all well and good. Except that MLOAD v2.1 has a bug where it overwrites the first 6 bytes of the CCP. Normally a warm restart rewrites the CCP, but where is doesn't (such as following an inbuilt CCP command), then oops. And, there's my symptom, a hang after a simple CCP command.

I've pushed MLOAD v2.5 up to the CP/M drives directory inside CP/M-IDE.

Perhaps that's the end of it.

[Phillip Stevens]

On 30 May 2018 at 10:15, phillip.stevens wrote:

Over the past few weeks I've been stalking an interesting (nasty) bug related to CP/M-IDE, CF cards, and the IDE interface.

Got a sniff of an answer, but it may be only partially right.

I was using MLOAD v2.1 to create my binaries after using PIP to transfer them, which was all well and good. Except that MLOAD v2.1 has a bug where it overwrites the first 6 bytes of the CCP. Normally a warm restart rewrites the CCP, but where is doesn't (such as following an inbuilt CCP command), then oops. And, there's my symptom, a hang after a simple CCP command.

I've pushed MLOAD v2.5 up to the CP/M drives directory inside CP/M-IDE, and a new version is in RunCPM too.

Perhaps that's the end of it.

The problem seems to have been simply MLOAD, and the bug present in v2.1.

With any implementation of CP/M, if you're not using version MLOAD v2.5, then I highly recommend finding it.

Phillip

[Phillip Stevens]

I've been studying MP/M sources, and documents and compared the disk deblocking routines in CP/M 2.2 and MP/M 2.1.

I find it very interesting that they are almost identical.

Given the rate of development in software, I guess a good job was done first time and since they weren't broken...

There are only a few simple changes, and I flowed them into the CP/M-IDE deblocking routines.

It saves a (very) few cycles on disk reads.

Phillip

[Phillip Stevens]

On Friday, 27 April 2018 12:43:50 UTC+10, Phillip Stevens wrote:

Now that the new SIO/2 drivers have been pulled into Z88DK and are part of the new -subtype=sio option, I've also created a new CP/M-IDE SIO build.

To write the SIO/2 drivers, I've gone back to the original datasheets and the Leventhal book from 1983 to see what they had to offer. For me it was a great learning experience with Z80 IM2 mode, and working for the first time with a Zilog peripheral device that could steer its interrupts using the IM2 interrupt response process. I always find it enlightening when I actually write the code, because the words in the datasheets don't mean that much to me until I have to study and "know" each bit.

Anyway, it is done now, and there are now two versions of CP/M-IDE. One for the ACIA, and the other for the SIO/2.

 

Also, now there is a Dr SM Baker SIO/2 build in the RC2014 Repository.

I don't have one of these boards, but since the only change is addressing the SIO/2, it should just work.

 Some build and usage notes.

For the SIO, to get to the shell prompt > after restarting the RC2014 use a colon : not a space.

Why? Because I can't see a space, and I like to know that I'm actually sending a character.

The SIO Port B is configured with no remote echo. That is usual for TTY interfaces, that might waste bandwidth by sending echo characters back. Use local echo.

The SIO Port A is configured with echo as normal. These options are just Z88DK input terminal configurations, that can be easily changed at build time.

DDT works with the SIO implementation, but it doesn't work with the ACIA version.

This is because of the use of the RST38 interrupt for IM1 mode. Other threads have covered this.

A lot of people seem to report troubles with Compact Flash cards in 8 bit mode.

Perhaps try using Ed's IDE card or Spencer's IDE card to drive the CF in PATA 16 bit mode?

It might take away some pain.

There are a few notes about the things that need to be configured in z88dk to convert from Spencer's SIO/2 to Dr Baker's SIO/2 in the commit comment.

But, a diff of the two builds shows the few bytes that needed to change.

Since quite a few ingredients into CP/M-IDE build have been updated recently, I've compiled and released a new version today.

But, of course the standard CP/M implementation provided hasn't changed (in quite a few decades).

• ChaN has released a v0.14 of FatFS, and that is included.
• The ZSDCC 3.9.3 has been in use for some time and was used for the compilation,
• An issue was resolved with the ZSDCC peephole optimisation (oops paste replace #1304) at z88dk which means that it builds from late this year could be suspect.

As usual the Hex Files are in the RC2014 Repository under CP/M-IDE for both ACIA and SIO serial boards.

Cheers, Phillip

[Phillip Stevens]

Phillip Stevens wrote:

Anyway, there are now two versions of CP/M-IDE. One for the ACIA, and the other for the SIO/2.

Also, now there is a Dr SM Baker SIO/2 build in the RC2014 Repository.

 Some build and usage notes.

For the SIO, to get to the shell prompt > after restarting the RC2014 use a colon : not a space.

Why? Because I can't see a space, and I like to know that I'm actually sending a character.

The SIO Port B is configured with no remote echo. That is usual for TTY interfaces, that might waste bandwidth by sending echo characters back. Use local echo.

The SIO Port A is configured with echo as normal. These options are just Z88DK input terminal configurations, that can be easily changed at build time.

DDT works with the SIO implementation, but it doesn't work with the ACIA version.

This is because of the use of the RST38 interrupt for IM1 mode. Other threads have covered this.

 

Since quite a few ingredients into CP/M-IDE build have been updated recently, I've compiled and released a new version today.

But, of course the standard CP/M implementation provided hasn't changed (in quite a few decades).

• ChaN has released a v0.14 of FatFS, and that is included.

• The ZSDCC 4.0.0 has been in use for some time and was used for the compilation,

In another place there was some discussion about converting the default number of files in a drive to 1024.

I was planning to make this change for CP/M-IDE too, and so there's no time like now.

So, I've built a new version with the 1024 file 16MB file modification for CP/M-IDE.

It is a trivial change. Just notify the BIOS that there are 1024 directory entries, and reserve sufficient allocation blocks for the directory entries. Changes only 3 bytes.

It took only a little while to rework all my drives into the new format. And it was quite simple using cpmtools commands to copy the contents of the legacy formatted drive to a directory, and then copy them back onto a a newly formatted drive.

> cpmcp -f rc2014v1-16MB USER.CPM 0:*.* ~/Desktop/cpm_drives/user.cpm/
> cpmcp -f rc2014-16MB USER.CPM ~/Desktop/cpm_drives/user.cpm/*.* 0:

This new disk definition needs to be copied to the cpmtools diskdefs file. In linux this is found in /etc/cpmtools/diskdefs

diskdef rc2014-16MB
  seclen 512
  tracks 1024
  sectrk 32
  blocksize 4096
  maxdir 1024
  skew 0
  boottrk -
  os 2.2
end

As usual the Hex Files are in the RC2014 Repository under CP/M-IDE for both ACIA and SIO serial boards.

Enjoy, P

[Phillip Stevens]

Phillip Stevens wrote:

Anyway, there are now two versions of CP/M-IDE. One for the ACIA, and the other for the SIO/2.

Also, now there is a Dr SM Baker SIO/2 build in the RC2014 Repository.

 Some build and usage notes.

For the SIO, to get to the shell prompt > after restarting the RC2014 use a colon : not a space.

Why? Because I can't see a space, and I like to know that I'm actually sending a character.

The SIO Port B is configured with no remote echo. That is usual for TTY interfaces, that might waste bandwidth by sending echo characters back. Use local echo.

The SIO Port A is configured with echo as normal. These options are just Z88DK input terminal configurations, that can be easily changed at build time.

DDT works with the SIO implementation, but it doesn't work with the ACIA version.

This is because of the use of the RST38 interrupt for IM1 mode. Other threads have covered this.

 

Since quite a few ingredients into CP/M-IDE build have been updated recently, I've compiled and released a new version today.

But, of course the standard CP/M implementation provided hasn't changed (in quite a few decades).

• ChaN has released a v0.14 of FatFS, and that is included.
• The ZSDCC 4.0.0 has been in use for some time and was used for the compilation,

In another place there was some discussion about converting the maximum number of files in a drive to 1024 or 2048.

I was planning to make this change for CP/M-IDE too, and so there's no time like now.

 

And so I've learned that CP/M 2.2 can only support 8 MB files, because of 16-bit arithmetic used when calculating ARECORD offsets.

SO I'VE UPDATED V2.0 TO USE 8MB DRIVES WITH UP TO 2048 FILES, AS BELOW.

 

It is a trivial change. Just notify the BIOS that there are up to 2048 directory entries, and reserve sufficient allocation blocks for the directory entries. Changes only 3 bytes.

It took only a little while to rework all my drives into the new format. And it was quite simple using cpmtools commands to copy the contents of the legacy formatted drive to a directory, and then copy them back onto a a newly formatted drive.

> cpmcp -f rc2014v1-16MB USER.CPM 0:*.* ~/Desktop/cpm_drives/user.cpm/


> cpmcp -f rc2014-8MB USER.CPM ~/Desktop/cpm_drives/user.cpm/*.* 0:

This new disk definition needs to be copied to the cpmtools diskdefs file. In linux this is found in /etc/cpmtools/diskdefs

diskdef rc2014-8MB
  seclen 512
  tracks 512
  sectrk 32
  blocksize 4096
  maxdir 2048


  skew 0
  boottrk -
  os 2.2
end

[Phillip Stevens]

Phillip Stevens wrote:

Anyway, there are now two versions of CP/M-IDE. One for the ACIA, and the other for the SIO/2.

Also, now there is a Dr SM Baker SIO/2 build in the RC2014 Repository.

 Some build and usage notes.

For the SIO, to get to the shell prompt > after restarting the RC2014 use a colon : not a space.

Why? Because I can't see a space, and I like to know that I'm actually sending a character.

The SIO Port B is configured with no remote echo. That is usual for TTY interfaces, that might waste bandwidth by sending echo characters back. Use local echo.

The SIO Port A is configured with echo as normal. These options are just Z88DK input terminal configurations, that can be easily changed at build time.

 

Since quite a few ingredients into CP/M-IDE build have been updated recently, I've compiled and released a new version today.

But, of course the standard CP/M implementation provided hasn't changed (in quite a few decades).

• ChaN has released a v0.14 of FatFS, and that is included.
• The ZSDCC 4.0.0 has been in use for some time and was used for the compilation,

In another place there was some discussion about converting the maximum number of files in a drive to 1024 or 2048.

I was planning to make this change for CP/M-IDE too, and so there's no time like now.

 

And so I've learned that CP/M 2.2 can only support 8 MB files, because of 16-bit arithmetic used when calculating ARECORD offsets.

SO I'VE UPDATED V2.0 TO USE 8MB DRIVES WITH UP TO 2048 FILES, AS BELOW.

 

It is a trivial change. Just notify the BIOS that there are up to 2048 directory entries, and reserve sufficient allocation blocks for the directory entries. Changes only 3 bytes.

It took only a little while to rework all my drives into the new format. And it was quite simple using cpmtools commands to copy the contents of the legacy formatted drive to a directory, and then copy them back onto a a newly formatted drive.

> cpmcp -f rc2014v1-16MB USER.CPM 0:*.* ~/Desktop/cpm_drives/user.cpm/
> cpmcp -f rc2014-8MB USER.CPM ~/Desktop/cpm_drives/user.cpm/*.* 0:

This new disk definition needs to be copied to the cpmtools diskdefs file. In linux this is found in /etc/cpmtools/diskdefs

 

 diskdef rc2014-8MB
  seclen 512
  tracks 64
  sectrk 256

  blocksize 4096
  maxdir 2048
  skew 0
  boottrk -
  os 2.2
end

Over the past few weeks I've been working on the differences between 32 SPT and 256 SPT, and have found that there is a performance improvement by using 256 SPT. That, together with using LDI to do sector deblocking and directory copies, and removing some 8080isms within the BDOS, has improved the disk throughput quite a bit. Yes this is tweaking the BDOS slightly from standard, but there are no impacts on compatibility. This has also resulted in an extra 1024 Bytes of TPA.

And, I think I'm finished now for a while. HEX files for RC2014 Plus + Spencer's IDE interface in the usual place.

Enjoy Phillip

[Phillip Stevens]

On Saturday, 9 May 2020 Phillip wrote:

Anyway, there are now two versions of CP/M-IDE. One for the ACIA, and the other for the SIO/2.

Well this has been stable for quite some time.

But following up on another discussion about effectively using "shadow" memory from 128kB RAM solutions, I've completed a useful addition to CP/M-IDE.

As background, there's info about CP/M-IDE here. Its designed to be cheap, fast, and very vanilla CP/M.

But as it uses FAT formatted hard drives (DOM, CF, IDE, 40 pin, 44 pin), you can store as many "CP/M drive" files on your hard drive as you like. Literally thousands of CP/M drives are possible.

And since Spencer's now got a new stock of IDE Hard Drive Modules on hand, let's get started. This IDE Module works much more reliably than 8 bit CF Modules.

There are some RC2014 compatible memory systems that are built with 128kB RAM devices, and these are now enabled to support the additional 64kB of RAM from C and assembly CP/M applications.

The SC108 Processor Module, the SC114 SBC, the Pickled Dog RAM/ROM, and the simple Memory Module, are four examples of memory systems that will work.

Anything that toggles the RAM at 0x30 and toggles ROM at 0x38 will work.

 Some build and usage notes.

For the SIO, to get to the shell prompt > after restarting the RC2014 use a colon : not a space.

Why? Because I can't see a space, and I like to know that I'm actually sending a character.

The SIO Port B is configured with no remote echo. That is usual for TTY interfaces, that might waste bandwidth by sending echo characters back. Use local echo.

The SIO Port A is configured with echo as normal. These options are just Z88DK input terminal configurations, that can be easily changed at build time.

And, I think I'm finished now for a while. HEX files for RC2014 Plus + Spencer's IDE interface in the usual place.

Here's an example program that generates 4kB of random info, copies it to the shadow RAM and a copy, deletes the original, and then copies it back.

Nothing is lost, which we like to see. Usage of the additional RAM is designed to be simple.

/*

% zcc +rc2014 -subtype=cpm -SO3 -m --list --max-allocs-per-node40000 main.c -o shadow -create-app

*/

#include <stdlib.h>

#include <stdio.h>

#include <string.h>

#include <arch/rc2014.h>

#pragma printf = "%s %c %d %x"     // enables %s, %c, %d, %x conversions only

#define BUFFER  4096

static uint8_t * front_ram;

static uint8_t * front_ram_copy;

int main()

{

        int16_t i;

        front_ram = (uint8_t *)malloc( BUFFER );

        front_ram_copy = (uint8_t *)malloc( BUFFER );

        srand( 42 );                        // definitely random

        for (i = 0; i < BUFFER; ++i)        // fill buffer with random stuff

        {

          front_ram[i] = (uint8_t) rand();

          printf("0x%02x ",front_ram[i]);

        }

        memcpy( front_ram_copy, front_ram, BUFFER );

        shadow_write( (uint8_t *) 0x8000, front_ram, BUFFER );

        memset(front_ram, '0', BUFFER);

        shadow_read( front_ram, (uint8_t *) 0x8000, BUFFER );

        i = memcmp( front_ram, front_ram_copy, BUFFER );

        printf("\n\nZero is good: %d", i );

        return (0);

}

So how does it work?

I'll use the SIO/2 version for example, but the ACIA version is identical. When the CP/M-IDE Shell loads, the ROM based z88dk crt0 code decompresses and writes out the shadow_copy program into both the main RAM and the shadow RAM. The shadow_copy code is in the "self modifying code" SECTION, which forces it to be located into RAM on boot, and allows the code to be stored compressed as a side benefit.

Then during the CP/M boot process the location of the shadow_copy code is written to the fixed location 0x0058, a reserved and unused location in CP/M. This location is important as it allows us to relocate the shadow_copy code anywhere, provided its location is maintained at 0x0058. Then this is used by the shadow_relocate function to move the shadow_copy code up in to a reserved location in BIOS BSS space during the CP/M boot process. where it resides unless we want to move it again (unlikely).

The two C functions shadow_write() and shadow_read() can then be used freely to move data back and forward.

Note that these two functions don't care where the current location of the shadow_copy code is located, they find it via the 0x0058 address.

Next step is to write CP/M applications using the additional RAM, like a text editor, or assembler, or something else useful.

HEX files for CP/M-IDE are in the usual place.

Phillip

 

[Phillip Stevens]

On Thursday, 11 November 2021 Phillip wrote:

Anyway, there are now two versions of CP/M-IDE. One for the ACIA, and the other for the SIO/2.

As background, there's info about CP/M-IDE here. Its designed to be cheap, fast, and very vanilla CP/M.

But as it uses FAT formatted hard drives (DOM, CF, IDE, 40 pin, 44 pin), you can store as many "CP/M drive" files on your hard drive as you like. Literally thousands of CP/M drives are possible.

And since Spencer's now got a new stock of IDE Hard Drive Modules on hand, let's get started. This IDE Module works much more reliably than 8 bit CF Modules.

There are some RC2014 compatible memory systems that are built with 128kB RAM devices, and these are now enabled to support the additional 64kB of RAM from C and assembly CP/M applications.

The SC108 Processor Module, the SC114 SBC, the Pickled Dog RAM/ROM, and the simple Memory Module, are four examples of memory systems that will work.

Anything that toggles the RAM at 0x30 and toggles ROM at 0x38 will work.

I've just finished a new CP/M-IDE platform for the 8085 CPU Module.

Perhaps it is the first 8085 based CP/M for the RC2014 platform?.

There is almost complete similarity between the different platforms (Z80 / 8085 and ACIA / SIO) from the DRI CCP and BDOS, as would be expected since they're written for 8080.

I took the opportunity to rewrite all of my ACIA and IDE code to make it 8080 compliant so that it would support both Z80 and 8085.

There are still differences in processor prologue code in the BIOS but there are a lot more similarities.

Differencing the directories will highlight these few differences.

Since the 8085 CPU Module breaks out the 8085 SOD pin to an FTDI interface, I've added a LPT: device to the normal CRT: on the ACIA interface.

CP/M-IDE Code here as usual.

Happy Retro New Year.

Phillip

[Fred 1]

just arrived for me those compact flash ide44/2.0 mm adaptor, pretty much as in the image IMG_0532.jpg

compactflash adaptor

I am just wondering what is the connector (female) plugged into it, part-no hopefully ?

(connector searches on mouser not exactly easy)

I have a ide cable here with 20+19pin connectors on it,  it don't fit those.

thanks

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/407692e6-dabd-4db6-8b3b-505593e98846n%40googlegroups.com.

[Phillip Stevens]

Fred wrote:

just arrived for me those compact flash ide44/2.0 mm adaptor, pretty much as in the image IMG_0532.jpg

compactflash adaptor

I am just wondering what is the connector (female) plugged into it, part-no hopefully ?

Usually the 44pin female IDE extension cables come with Laptop Hard Drives. I think that's where I got mine from.

But, this search on eBay finds quite a few options. "44-pin female ide cable".

https://www.ebay.com/sch/i.html?_from=R40&_nkw=44-pin+female+ide+cable

If you know a local PC shop they'd probably give you one to get rid of it.

Just for reference, I've settled on "44-pin IDE Disk On Module Horizontal PATA" as my drive preference.

They fit into the IDE adapter profile, making the RC2014 very streamlined and clean. For about US$8 it is a good solution.

See bottom left int the picture that it fits over the IDE Module profile.

But, you do need a "reverser" connection to swap the pin sides over when you want to use the DOM on a PC as a normal external drive with a normal cable when you want to load it with CP/M drive files.

That fiddling is just used occasionally. So I can live with that.

Cheers, Phillip

[Fred 1]

hmm i see, thanks Phillip

ok, so more parts before i can experiment with CF.... ebay from china is taking forever....strangely though aliexpress quite qik, < 4weeks (to australia)

On 01/01/2022 12:03, Phillip Stevens wrote:

44-pin female ide cable

[Phillip Stevens]

On Thursday, 30 December 2021 at 14:47:58 UTC+11 Phillip Stevens wrote:

As background, there's info about CP/M-IDE here. Its designed to be cheap, fast, and very vanilla CP/M.

But as it uses FAT formatted hard drives (DOM, CF, IDE, 40 pin, 44 pin), you can store as many "CP/M drive" files on your hard drive as you like. Literally thousands of CP/M drives are possible.

And since Spencer's now got a new stock of IDE Hard Drive Modules on hand, let's get started. This IDE Module works much more reliably than 8 bit CF Modules.

I've just finished a new CP/M-IDE platform for the 8085 CPU Module.

Perhaps it is the first 8085 based CP/M for the RC2014 platform?.

Since the 8085 CPU Module breaks out the 8085 SOD pin to an FTDI interface, I've added a LPT: device to the normal CRT: on the ACIA interface.

CP/M-IDE Code here as usual.

A New Year update on how to compile programs targeting the 8085 CPU and CP/M-IDE.

I've been through many of the z88dk examples and benchmarks (z88dk-classic library version), and found that they're all working well.

The fastest floating point library available today is the Microsoft MBF-32 version (which we've also adapted to 8085).

Here's some examples to start with.

Startrek

zcc +cpm -clib=8085 -O2 startrek.c -o startrek --math-mbf32_8085 -create-app

Pi

zcc +cpm -clib=8085 -O2 -DSTATIC -DPRINTF pi.c -o pi -lndos -create-app

Whetstone

zcc +cpm -clib=8085 -O2 -DSTATIC -DPRINTOUT whetstone.c -o whetstone --math-mbf32_8085 -lndos -create-app

Cheers, Phillip

[Phillip Stevens]

On Monday, 3 January 2022 at 20:41:47 UTC+11 Phillip Stevens wrote:

As background, there's info about CP/M-IDE here. Its designed to be cheap, fast, and very vanilla CP/M.

But as it uses FAT formatted hard drives (DOM, CF, IDE, 40 pin, 44 pin), you can store as many "CP/M drive" files on your hard drive as you like. Literally thousands of CP/M drives are possible.

And since Spencer's now got a new stock of IDE Hard Drive Modules on hand, let's get started. This IDE Module works much more reliably than 8 bit CF Modules.

I've just finished a new CP/M-IDE platform for the 8085 CPU Module.

Perhaps it is the first 8085 based CP/M for the RC2014 platform?.

Since the 8085 CPU Module breaks out the 8085 SOD pin to an FTDI interface, I've added a LPT: device to the normal CRT: on the ACIA interface.

CP/M-IDE Code here as usual.

 A little admission, hopefully amusing...

I've spent quite a bit of time over the past weeks chasing down an issue that I was getting when assembling 8080 code with the ASM.COM program.

The same error was apparent in both Z80 and 8085 versions of CP/M-IDE, so it wasn't new stuff I was doing.

Basically, I was feeding the ASM program with a command and it was returning with the message: Bdos Err On M: Select

Now the only way to get this message returning from the BDOS was is to try to select the M: drive and in a 4 drive system this is impossible, unless there's a bug somewhere.
So I've been digging through the ASM source code and reversing along the CP/M-IDE BDOS trying to track where my code was going wrong.

Managed to improve a few things along the way, but no hints at all as to why things were going astray.

Finally, I've worked out what was causing the problem.

The ASM.COM program (interestingly) takes its configuration parameters as three letters following the file extension dot.

So asking the program to assemble MYCODE.ASM like this:

A> ASM MYCODE.ASM

Is actually asking to read the A: drive, and write the  HEX file output to S: drive, and write the PRN output to the M: drive.

Neither of which exist.

Doh! Got to remember to RTFM.

[Mark T]

I remember seeing that before and thinking what a stupid nonstandard way to define source and destinations.

[Andrew Herron]

Hi,

Newbie question;

Is there any reason why an SD card could not be used instead of a DOM using an adapter like this?; https://www.amazon.co.uk/dp/B08SK4G7RP?ref_=cm_sw_r_cp_ud_dp_EF0NY9XV105ER3B6B8PJ

Andy

[Phil G]

>> Is actually asking to read the A: drive, and write the  HEX file output to S: drive, and write the PRN output to the M: drive.

same with ZSM,   I quite like it that way!  You can also default all three to the current drive using ZSM MYFILE.@@@

[Phillip Stevens]

Andy wrote:

Is there any reason why an SD card could not be used instead of a DOM using an adapter like this?; https://www.amazon.co.uk/dp/B08SK4G7RP?ref_=cm_sw_r_cp_ud_dp_EF0NY9XV105ER3B6B8PJ

I’ve never tested the use of an SD Card in an adapter like this as an IDE Disk. It would be an interesting experiment to try. If you have one of Spencer’s IDE Modules you can give it a go.

The adapter would need to emulate PIO Mode 0 (the slowest mode), but since the standard includes this mode there is no reason why it wouldn’t do it.

But, given the expense (£16.99 plus a SD Card about £5.00), I’d still use a cheap DOM in preference.

Cheers, Phillip

[Phillip Stevens]

Andy wrote:

Is there any reason why an SD card could not be used instead of a DOM using an adapter like this?; https://www.amazon.co.uk/dp/B08SK4G7RP?ref_=cm_sw_r_cp_ud_dp_EF0NY9XV105ER3B6B8PJ

Since the last update on CP/M-IDE there have been quite a few developments.

Firstly Dylan developed a new PPIDE CF Module specifically for the Compact Flash format. There was quite a bit of discussion on this but essentially this new Module directly supports CF Cards and is very robust. We haven't found a CF Card that the PPIDE Modules (both Spencer's and Dylan's) doesn't work with. They also support the SD to CF Adapters so that cheap SD or Micro SD cards (up to 128GByte) can be used as the CP/M-IDE host drive.

There was quite a bit of work within z88dk sccz80 on the Intel 8085 support functions. Now the full suite of inline code optimisations works with Intel 8085, which is nice. Based on that work, a new version of the CP/M-IDE for Intel 8085 was produced and added to the Release 2.2.

And,  finally I added a mkdrv command to yash. This means the the CP/M-IDE drive template file is now irrelevant, as any number of new CP/M "drive" files can be created, managed and then mounted from within CP/M-IDE.

From within CP/M-IDE, using the yash shell, new "drives" (or FATFS files) can be created, copied, renamed, moved, or deleted. New or existing drives can then be mounted on a CP/M drive letter, and then used directly from the CCP within CP/M.

> mkdrv mydrive.cpm  to create the drive. There are command line options to create non-standard numbers of directory extents or file size (which can be safely ignored).

> frag mydrive.cpm to check that the file was not created fragmented. This is an optional one time sanity check, if it makes you feel happy. The use of CP/M can not fragment its "drive" files.

> dmount d mydrive.cpm to mount the new drive on a new CP/M drive letter. You can overwrite an existing mounted CP/M drive to "swap" drives, although it is then best to ^C to log-in the new drive from the CCP before proceeding.

This also creates two options for duplicating "drives". Either the yash cp function can be used to duplicate the drive file on the FATFS disk. Or a new clean drive can be created and mounted by yash, and then CP/M PIP is used to copy files from the old drive to the newly created drive.

Anyway, this should make life easier for anyone using CP/M-IDE.

Don't know why I didn't do it previously.

And, that's all there is for now.

Phillip

 

[Phillip Stevens]

I've just done a new Version 2.3 Release of CP/M-IDE for 2023.

There have been two major additions since the last release, being support for Compact Flash (8-bit) IDE Modules and the inclusion of a shell hload function enabling CP/M applications to be loaded without any connected or enabled disk system.

Following a long collaborative thread on IDE (PPIDE and CF) Adapters I've provided two new versions of CP/M-IDE with support for CF Modules. One version for the RC2014 Pro completely standard hardware, and a second version for the 8085 CPU Module.

This now makes 5 different hardware versions supported, all based on the basic (inexpensive) RC2014 Pro hardware. It is possible to produce many further pre-prepared variations supporting alternate hardware (such as shadow RAM, and other serial modules), but I think it is getting into diminishing return to support them.

The standard CF Module v1.3 is supported by the two new versions (pro and acia85cf), but Tadeusz has produced a new CF Module v2.0 version that is fundamentally more reliable than previous CF Module iterations and his v2.0 version has been tested working with both large CF Cards (1GB and 2GB) and SD to CF Adapters.

The shell hload function enables precompiled CP/M applications or programs to be uploaded to RAM and run without loading CP/M and without any CP/M disk system attached. The program must be encoded in Intel HEX, and it can use the CP/M BDOS serial APIs but the BDOS disk APIs are not supported (as it is assumed no disk is attached). Typically the program would be loaded from 0x0100 address and run, but there is no obligation to do this. The program is initialised by jumping to the first address found encoded in the HEX, once the program is loaded, and this can be anywhere.

The hload function can be used to load a program which can then format FATFS disks, create CP/M drive files, and also manage FATFS disks, without reliance on CP/M. It can also be used to directly load CP/M games or debugging programs as needed without reliance on CP/M.

As I'd like to avoid scope creep, I'd like this to be the last major set of changes for CP/M-IDE. It now does everything that a CP/M system needs to do, and it is as optimised as I can make it. Obviously, I'll be continuing to maintain the code base and will provide fixes if and when issues are found.

But I think for now, we're done.

Phillip

[Phillip Stevens]

z88dk recently merged the newly released sdcc v4.3.0 compiler.

To test that everything is working as expected, I've recompiled the ChaN FatFS library and CP/M-IDE (and quite a few other libraries too).

The revised CP/M-IDE Z80 ROMs have been added to the CP/M-IDE v2.3 Release.

There has been no change in function, so I just updated the relevant HEX files.

The 8085 ROMs are compiled with z88dk sccz80, and are therefore not affected by this update.

That's all for now.

Cheers, Phillip

On Wednesday, 18 January 2023, Phillip wrote:

I've just done a new Version 2.3 Release of CP/M-IDE for 2023.

There have been two major additions since the last release, being support for Compact Flash (8-bit) IDE Modules and the inclusion of a shell hload function enabling CP/M applications to be loaded without any connected or enabled disk system.

Following a long collaborative thread on IDE (PPIDE and CF) Adapters I've provided two new versions of CP/M-IDE with support for CF Modules. One version for the RC2014 Pro completely standard hardware, and a second version for the 8085 CPU Module.

This now makes 5 different hardware versions supported, all based on the basic (inexpensive) RC2014 Pro hardware. It is possible to produce many further pre-prepared variations supporting alternate hardware (such as shadow RAM, and other serial modules), but I think it is getting into diminishing return to support them.

The standard CF Module v1.3 is supported by the two new versions (pro and acia85cf), but Tadeusz has produced a new CF Module v2.0 version that is fundamentally more reliable than previous CF Module iterations and his v2.0 version has been tested working with both large CF Cards (1GB and 2GB) and SD to CF Adapters.

The shell hload function enables precompiled CP/M applications or programs to be uploaded to RAM and run without loading CP/M and without any CP/M disk system attached. The program must be encoded in Intel HEX, and it can use the CP/M BDOS serial APIs but the BDOS disk APIs are not supported (as it is assumed no disk is attached). Typically the program would be loaded from 0x0100 address and run, but there is no obligation to do this. The program is initialised by jumping to the first address found encoded in the HEX, once the program is loaded, and this can be anywhere.

The hload function can be used to load a program which can then format FATFS disks, create CP/M drive files, and also manage FATFS disks, without reliance on CP/M. It can also be used to directly load CP/M games or debugging programs as needed without reliance on CP/M.

As I'd like to avoid scope creep, I'd like this to be the last major set of changes for CP/M-IDE. It now does everything that a CP/M system needs to do, and it is as optimised as I can make it. Obviously, I'll be continuing to maintain the code base and will provide fixes if and when issues are found.

[Phillip Stevens]

z88dk recently merged the newly released sdcc v4.5.0 compiler.

To test that everything is working as expected, I've recompiled the ChaN FatFS library (which also has been updated to v15a patch 1) and CP/M-IDE (and quite a few other libraries too).

These revised CP/M-IDE Z80 and 8085 ROMs have been added to the CP/M-IDE v2.3 Release.

There has been no change in function, so I just updated the relevant HEX files.

The 8085 ROMs are compiled with z88dk sccz80 and are linked with the recompiled ChaN FatFS libraries, and they now used optimised comparison library routines.

Check out CP/M-IDE here.

Cheers, Phillip

[Phillip Stevens]

On Thursday, 22 March 2018 at 22:22:41 UTC+11 phillip.stevens wrote:

For a long time, I've been looking at making a very cut down version of CP/M for the RC2014.

Able to work off the minimum set of cards and most importantly being able to load from ROM and from FATFS formatted IDE drives.

Happy to report that CP/M-IDE turned 7 years old, yesterday. 🎉🥳

As a minimum solution to get CP/M running off “spinning rust”, not much has changed over the years, except some ease of use features.

But support has been extended to 8085 CPUs, and to the revised CF Module. And recently the Single and Dual UART Modules have also been added to the build options.

[Phillip Stevens]

There is now a new Version 2.4 Release of CP/M-IDE.

CP/M-IDE is designed to be a very simple and easy to use implementation of CP/M for the original RC2014 Pro, which can be run off standard FATFS formatted Compact Flash Cards or SD Adaptors or, more originally, off spinning-rust parallel attached hard drives (PATA IDE). Since the original release supporting Spencer's IDE Hard Drive Module, support for a variety of Serial Modules, the CF Module V2.0, and also the 8085 CPU Module has been added.

There is no need for disk loaders or special applications, special formatting, or other disk preparation operations.

Just copy some CP/M disks onto the Compact Flash Module and you're done. If the Compact Flash Card is large, enough hundreds of 8MBbyte drives can be stored ready for use as needed.

The focus is on efficiency, minimising driver overhead and maximising the space available for applications.

It is designed for 64kB RAM solutions, with a variety of memory modules supported, and has a greater free TPA available than comparative solutions.

This new release adds only a few minor functional changes, noted below. Otherwise it is just minor updates and polishing.

• Added BDOS functions #37 Selectively reset disc drives, and #40 Write random with zero fill, which had been omitted.
• Made the shell disk access functions interrupt safe. No effect on CP/M, as these functions are not used there.
• Updated FatFS to use version 15a patch 1 for shell disk access.
• Locked the current LBA address storage location to 0xF800 for consistency across different builds.
• Optimisations of 8085 shell through better compiler support for comparison and stack operations.

Caveats?

UART Module

Although I'd hoped to have the UART Module support ready, there are still some issues with the TI 16C2550 device which mean that I've not published the actual HEX builds. Of course the source code remains in the repository and I hope to add the released UART Module support shortly.

POWER 3.08 Application

There are issues with the POWER 3.08 file management application. It is an application that does some advanced file access. I've spent quite some time investigating what it is doing, and have found that it uses BDOS call #50 often. This BDOS call is not supported by CP/M 2.2, yet the program works successfully on other CP/M 2.2 implementations. I'm at a loss as to what this application is doing (or assuming) that CP/M-IDE doesn't provide.

Anyway, any feedback or thoughts, please let me know.

P.

[Phillip Stevens]

On Tuesday, 17 June 2025, Phillip Stevens wrote:

There is now a new Version 2.4 Release of CP/M-IDE.

POWER 3.08 Application

There are issues with the POWER 3.08 file management application. It is an application that does some advanced file access. I've spent quite some time investigating what it is doing, and have found that it uses BDOS call #50 often. This BDOS call is not supported by CP/M 2.2, yet the program works successfully on other CP/M 2.2 implementations. I'm at a loss as to what this application is doing (or assuming) that CP/M-IDE doesn't provide.

This caveat now fixed.

One of the silly things BDOS does on entry is to jump to itself, just leaving a gap of 8 bytes.

So I had removed that jump to optimise out (10 cycles) of silliness, and started directly with the entry code.

PUBLIC      _cpm_bdos_fbase
_cpm_bdos_fbase:            ;entry for the cpm bdos
    JP      FBASE

    DEFS    8               ;error vectors

;
;   Entry into bdos. (DE) or (E) are the parameters passed. The
;   function number desired is in register (C).
;
FBASE:
    EX      DE,HL           ;save the (DE) parameters.
    LD      (PARAMS),HL

Evidently the author of POWER thought the same thing, because he uses the jump destination address to calculate his own optimised "direct BDOS entry" point. But the upshot of that is if you optimise BDOS by removing that jump on entry, POWER can no longer do that trick, so it fails.

So I’ve removed my optimisation, and now POWER 3.03 and POWER 3.08 work as expected.

Everything will be just a bit slower, but that is the price for compatibility. ;-)

New HEX files are checked in at the repository.

Cheers,

P.

 

[Jonathan Harston]

On Tuesday, 24 June 2025 at 13:32:32 UTC+1 Phillip Stevens wrote:

One of the silly things BDOS does on entry is to jump to itself, just leaving a gap of 8 bytes.

So I had removed that jump to optimise out (10 cycles) of silliness, and started directly with the entry code.

PUBLIC      _cpm_bdos_fbase
_cpm_bdos_fbase:            ;entry for the cpm bdos
    JP      FBASE

    DEFS    8               ;error vectors

;
;   Entry into bdos. (DE) or (E) are the parameters passed. The
;   function number desired is in register (C).
;
FBASE:
    EX      DE,HL           ;save the (DE) parameters.
    LD      (PARAMS),HL

That is the specific specfied layout of the BDOS, specifically so that - as you have

seen - you can find the BDOS entries and other code. Here is the original 1979 DR code:

jmp bdose ;past parameter block
;
; ************************************************
;       *** relative locations 0009 - 000E           ***
; ************************************************
;
pererr: dw persub ;permanent error subroutine
selerr: dw selsub ;select error subroutine
roderr: dw rodsub ;ro disk error subroutine
roferr: dw rofsub ;ro file error subroutine
;
;
bdose: ;arrive here from user programs
xchg

[Phillip Stevens]

On Wednesday, 25 June 2025, Jonathan Harston wrote:

On Tuesday, 24 June 2025 at 13:32:32 UTC+1 Phillip Stevens wrote:

One of the silly things BDOS does on entry is to jump to itself, just leaving a gap of 8 bytes.

So I had removed that jump to optimise out (10 cycles) of silliness, and started directly with the entry code.

That is the specific specfied layout of the BDOS, specifically so that - as you have

seen - you can find the BDOS entries and other code. Here is the original 1979 DR code:

jmp bdose ;past parameter block
;
; ************************************************
;       *** relative locations 0009 - 000E           ***
; ************************************************
;
pererr: dw persub ;permanent error subroutine
selerr: dw selsub ;select error subroutine
roderr: dw rodsub ;ro disk error subroutine
roferr: dw rofsub ;ro file error subroutine
;
;
bdose: ;arrive here from user programs
xchg

Yes, you're correct that as the contents of the BDOS were unravelled, and later when the original source code was published, it became clear what DRI was doing inside their BDOS "sausage factory". Certainly, by the time that Pavel Breder was writing the POWER application the internals of the BDOS were well documented. Indeed he used that knowledge to unravel the internal silliness and build an optimised entry point for himself.

But the formal BDOS entry point has always been defined as the call to 0x0005 which contained a jump and the address of the entry point (at 0x0006). What happened after that is "sausage factory". The code was distributed as a binary, and used MOVCPM to relocate it depending on the machine To quote the CP/M Operating System Manual.

"BDOS: Basic Disk Operating System. The BDOS module of the CP/M operating system provides an interface for a user program to the operating. This interface is in the form of a set of function calls which may be made to the BDOS through calls to location 0005H in page zero. The user program specifies the number of the desired function in register C. User programs running under CP/M should use BDOS functions for all I/O operations to remain compatible with other CP/M systems and future releases."

So it is an interesting historical phenomenon that, to my knowledge, no other application writer has used their knowledge of internals of the BDOS to their advantage. I've used quite a few CP/M applications, including those that you might think would do strange things (like NZCOM or ZCPR), or DRI internal applications written by the original CP/M authors, and yet all of them have stuck to the formal process of calling BDOS. It would be interesting to know of any other historical application that did a similar optimisation.

For those interested in POWER itself, it is worthwhile noting that Pavel supported the 8080, at least up to v3.03.

But, the most recent version v3.08 was a Z80 only build.

Cheers,
P.

[Richard Deane]

Phillip, 

Thank you, v2.4 of CPM-IDE is working for me and cures the Power 3.08 problem as you expected.

I have identified that the problem I was having with the debugger Z8E2 is that it is assembled either as a CPM3 flavour or a CPM22 flavour. I was attempting to run a CPM3 flavour on CPM-IDE (i.e. CPM22). Changing the CPM3 equate to false and rebuilding has cured that problem.

Cheers

Richard

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rc2014-z80/ed4a4167-7d5c-4f97-839f-3460e2474c8dn%40googlegroups.com.

[Jonathan Harston]

On Wednesday, 25 June 2025, Jonathan Harston wrote:
> That is the specific specfied layout of the BDOS, specifically so that - as you have
> seen - you can find the BDOS entries and other code. Here is the original 1979 DR code:
>
> jmp bdose ;past parameter block

> pererr: dw persub ;permanent error subroutine
> selerr: dw selsub ;select error subroutine
> roderr: dw rodsub ;ro disk error subroutine
> roferr: dw rofsub ;ro file error subroutine
>         ;
> bdose: ;arrive here from user programs
>         xchg

Phillip Stevens wrote:
> But the formal BDOS entry point has always been defined as the call to 0x0005 which
> contained a jump and the address of the entry point (at 0x0006).

(0006) was also always defined at the top of usable memory. Code was able to modify
(0006) to point to a lower address to claim memory at the top of memory, and put a
JP to the read BDOS there to chain on to the actual BDOS.

Phillip Stevens wrote:
> So it is an interesting historical phenomenon that, to my knowledge, no other
> application writer has used their knowledge of internals of the BDOS to their

> advantage. (...)

On this topic, are the four error vectors used by anything other than the BDOS itself?
Are they allowed to be read by user applications? Are they allowed to be written by
user applications?

I have some code that resides in high memory and drops the high water mark pointed to
by the JP BDOS entry at 0005 to point to itself, so defining a new high water mark,
and copies the first 11 bytes from the BDOS to itself, so allowing CALL 5 to jump to
my new code which then jumps onward to the actual BDOS code.

So, my code looks like this:
NEWHIGHMEM
JP  0 ; Will be filled in with BDOS header
DEFW 0
DEFW 0
DEFW 0
DEFW 0
...

INIT:

... some checks

LD HL,(6) ; HL=>start of existing BDOS
LD DE,NEWHIGHMEM ; DE=>start of my code
LD (6),DE ; Set JP BDOS to point to me
LD BC,11 ; Copy header to my new top of memory
LDIR
....

so when running, memory is:
0005 JP NEWHIGHMEM
...
NEWHIGHMEM:
xxx0 JP bdose
xxx3 DEFW persub
xxx5 DEFW selsub
xxx7 DEFW rodsub
xxx9 DEFW rofsub
...
my code
...
BDOSBASE:
yyy0 JP bdose ; start of actual BDOS
yyy3 DEFW persub
yyy5 DEFW selsub
yyy7 DEFW rodsub
yyy9 DEFW rofsub
rest of BDOS

So, code that reads (0006) to find the top of memory finds the top of memory -
underneath my code. Code that reads (0006) and looks to the following memory
finds the address of the error handling subroutines. And code, like POWER,
that reads (0006) and uses that to find where the JP bdose goes to will also
find the destination of the JP to bdose.

But, is there any code that looks for those error routine addresses? Code that
does something along the lines of:
LD HL,(6)
LD DE,3
ADD HL,DE
LD C,(HL)
INC HL
LD B,(HL) ; BC=permanent error subroutine

Even more crucially, is there code that attempts to find those vectors and
*changes* them? The BDOS itself references the absolute addresses at the
start of the BDOS, it doesn't look for them at an offset from (0006), eg:
it does:
DOWRITE:CALL WRITE
IORET: OR A
RET Z ;return unless an error occured.
LD HL,BADSCTR ;bad read/write on this sector.
JP JUMPHL

So, dropping (0006) to claim memory and copying the BDOS header to the new
high water mark would give a read-only copy of the error vectors, but
changing them would not change anything the BDOS does as the BDOS references
the original vectors up in the actual BDOS.

Is there any code that does change the error vectors with the expectation
that it can change what happens when an error occurs? Eg change to point to
its own code so it can deal with the errors and continue rather than the
BDOS displaying it to the console and then bombing out.

I can make my setup code scan through the BDOS to find the references to
the error vectors and patch them, and unpatch them when quitted. But is
it worth the code? Does anything actually write to the error vectors in
order to redirect them? And do alternative BDOSes also have the same
error vectors? A quick check at one alternative BDOS gives:

           ORG  LE006
BDOS_ENTRY:JP   LE012 ; Perform BDOS function call
BDOS_XXXX: JP   LE012 ; Perform BDOS function call
BDOS_COLD: JP   LE04A ; Called by BIOS Cold Start
BDOS_WARM: JP   LEA05 ; Called by BIOS Warm Start

!

JGH

[Phillip Stevens]

On Tuesday, 29 July 2025 at 07:08:22 UTC+9:30 Jonathan Harston wrote:

Phillip Stevens wrote:
> But the formal BDOS entry point has always been defined as the call to 0x0005 which
> contained a jump and the address of the entry point (at 0x0006).

(0006) was also always defined at the top of usable memory. Code was able to modify
(0006) to point to a lower address to claim memory at the top of memory, and put a
JP to the read BDOS there to chain on to the actual BDOS.

Yes, that’s the way that DDT and ZSID (for example). But interestingly, they don’t have any further requirements on the BDOS entry, as they worked correctly with my modified code.

Also the Microshell used this method too.

 

Phillip Stevens wrote:
> So it is an interesting historical phenomenon that, to my knowledge, no other
> application writer has used their knowledge of internals of the BDOS to their
> advantage. (...)

On this topic, are the four error vectors used by anything other than the BDOS itself?
Are they allowed to be read by user applications? Are they allowed to be written by
user applications?

I do not think they are used. Have a look at the different implementations of the BDOS in the RomWBW source code. They usually add many more data bytes to the header structure. So the size is not important. Also They’re usually all just pointing at the ERROR function. Though leaving them blank causes no problems either.

Here’s ZSDOS2 for example.

 https://github.com/wwarthen/RomWBW/blob/master/Source/ZSDOS2/zsdos2.z80

I guess that there was a thought to open further access to the BDOS, but those error functions and other things were never (to my knowledge) opened up.

Someone else might know better, but I’ve never seen any code that uses the BDOS internal error functions. Except of course BDOS itself. I’ve read fairly widely in the DRI documentation, and I’ve not seen any reference to use of this possibility. Perhaps I missed something, and if so then it would be good to know about it.

For interest, I’ve removed a layer of abstraction around the error functions in CP/M-IDE BDOS. Not changing the actual functions themselves, but rather just to call the functions themselves rather than an abstract call. Since the functions seem not to be externally documented, there seemed to be no problem with that.

Cheers, Phillip 

[Jonathan Harston]

CPM3 added a "return all errors to caller" function setting (BDOS 45), so maybe DR realised

"crash on error" was annoying to application writers, and realised they'd not actually

documented how to catch those errors, so explicitly made a BDOS call to catch them.

Interestingly,  John Elliott's documentation for BDOS 45 lists the CPM2 entries, with no

mention of if they are user-changable, and John's scoured loads of documentaion and

code to build his references. link