Drac: re your cct - I noticed these things and thought you might be interested...
If you have spare I/O you could connect (or link) another PS2 port (with pullups) on the miniDIn6 pins - there are breakout cables cheap on eBay.
I use a DJ21 with finer pins (from DigiKey). The holes are much smaller.
Have you thought of using an AV4 3.5mm for combined Stereo/TV? I have t/h sockets if you require some and the cables to 3 RCAs are cheap on ebay. Use the AV pinout, not iPhone - I can give you the details if reqd.
I'm reading through Rodney Zaks' book at the moment. Page 186 - each file control block links to the locations of 128 records, each of 128 bytes, so each file control block is a maximum of 16k. The largest CP/M file may have 16 of these units making the largest CP/M file 256k. Zaks says this is slightly larger than the largest 8 inch diskette.
I'd checked with available Digital Research's references (most CP/M 1.4, 2.0 and 2.2 Interface Guides) and the above cited file lenght limit of 256k only applies to CP/M 1.4.
Starting from CP/M 2.0 the record numbering was expanded: the last three bytes of the FCB can hold a number from 0 to 65535 in the two least significant bytes, overflowing to the third one only once.
This allows for 65,536 records of 128 bytes to be addressed by any FCB, or 8,192 kBytes as the maximum file lenght.
Back in the days CP/M was coded (end of 70's thru 80's) there was no such things as big capacity linearly addressable midia (at least not for our budgets, mere mortals) and thus there are many issues when dealing with hardware/software blocking and deblocking algorytms to make fully and optimized use of hard drives.
Today's SD's and memory disks easy things a lot.
That would make sense, as Zaks' book was written about the time things were transferring from CP/M 1.4 to 2.2. That also solves a puzzle where some books reference the last digits of the FCB being 2 bytes and some say 3. I could never work out what the third one was for as it was always zero, and I guess that was because all the files I looked at were under 256k.
Discovered a photo of my HDDs for my ICL mini while at my mothers today - 3 x 10MB washing machine sized drives with 6 high (10 head) 19" platter removable hard disks. Cost $16,000 each drive and about $400 per disc pack in 1976. I bought the whole system second hand - 18 months old in 1977.
I used CP/M 2.2 around 1983-5 with Apple /// and Microsoft Z80 card, plus a Corvus 5MB HDD. The drives were unreliable if powered up and down so they were left powered 24/7.
@heater, something you mentioned about compilers building jump tables for long select..case statements has got me thinking. I wrote a little test program and it does seem that is true to some extent in vb.net.
To do experiments with the bdos I need a simulator. And in the big upgrade from winXP to Win8, Visual Studio needed upgrading, and it seems my nifty code for talking directly to the SIMH no longer works. So I can't use the SIMH for rapid compilation.
Not sure the SIMH could quite do everything here anyway as one needs to hook into it in multiple places. So I have been writing a Z80 simulator in vb.net
I took an existing one written vb6 and heavily modified it. Not quite finished at the moment but you can get the general idea with the attached code. It is not optimised by any means (eg using the bit patterns to do jumps) but in general terms;
How on earth did you get this to fit in a Propeller??!!
That is a heroic effort what with vb.net running on the CLR and all that. I would have said you were crazy but then I remembered a story:
Someone was wanting to write an emulation of some old glass terminal in Java. All it had to do was interpret the control codes coming in and move the cursor around the terminal window, change text colours etc. Normal VT100 emulation kind of stuff.
Problem was they tried and tried but they could not emulate every little corner case of the terminal and their displays were never quite right.
Then they had an idea: We have the binary dump of the ROMs of the original terminal which used a 4040 or 8080 CPU. Lets's write an emulator for that processor in Java, emmbed it in our terminal software and have it do the work for us.
Bingo it worked! Every little bug in the original device being recreated perfectly.
But, surprise, surprise the CPU emulator, written in Java, running the termial ROMs code was faster than their straight Java terminal emulation!
...my nifty code for talking directly to the SIMH no longer works.
No idea about that. If I remember you can talk to SIMH via telnet. Is that what you were doing? I'm sure that will still work.
How on earth did you get this to fit in a Propeller??!!
Thank you for your clarification of maximum CP/M 2 file and disk sizes. That is in accordance with my understanding of the docs I found a few years back.
The Later versions of ZiCog use the maximum 8MB sized disks. No floppy disks.
Can't remember if we can drop in as many as 16 of those disks currently but I do remember experimenting with that and it eats up too much CP/M RAM for my taste.
To Heater, Dr_Acula, Cluso99 and everyone else in this thread.
Since I'm a curious one by nature, following the thoughts expressed in the threads and trying to aggregate some useful information became a very joyful and gratifying activity.
I wish to thank you all (and your posts, for sure) for giving me the opportunity of doing this.
The work you and your colleagues have done, bringing to the Propeller world a functional Z80 is outstanding.
Z80's were the third CPU that I have learned in my life. I love to revisit them.
And in my to do list is always pending a deep dive in the second O.S. that i'd put my hands on, and whose taste still persists more than three decades since the very first sip.
Studying this thread gives me opportunity to satisfy both needs.
Thanks. Do have a search of the forums for even more Z80 madness. There is also the qz80 emulator from PullMoll. He even got all the z80 instructions working. ZiCog is still missing a few (Must get round to fixing those). Luckily those instructions are almost never used in CP/M software.
Whatever RAM driver you have, cached or not, ZiCog needs a mail box interface (space in HUB) where it can request a read or write of a byte at any random location and get a suitable result. Of course to get any speed that RAM driver had better be written in PASM.
I'm just now getting to remind myself how all this works. It's sounds quite doable though.
In theory, I think it is one 8pin serial SPI ram chip and a propeller chip. Debug via the serial port, and then later if you want, add a keyboard and TV/VGA as per the standard schematics.
I say "in theory", because the code hasn't been written yet. The existing hardware is lots of latches and a parallel sram chip. But the boffins over on the C forum have shown that the performance of slow serial ram but with caching can be superior to parallel ram.
I think one reason no-one looked at the serial ram back 3 years ago was that at the time, those chips only had 32k. But there is now a 128k serial ram chip which is twice what you would need for zicog.
What is needed is a fusion of the cache code and the zicog. Then this whole thing could be done with one propeller and an 8 pin chip.
In terms current working minimum schematics the last ZiCog versions put out by me were running on the middle Prop chip of Cluso's TriBlade board.
See for example page 46 of this thread (zicog_cpm_lmm.zip) I'm sure Cluso can supply the schematic of that.
Cluso also has it running on his tiny RamBlade and Dr_A has his own solutions.
I guess it is time to up grade all of this to more modern solutions with readily available boards and RAM setups. A simple serial RAN solution would be great.
I have just released a new OS which can be used on the RamBlades and TriBlade as well as other hardware. This OS is intended to replace the current shipped OS which was derived from PropCmd. The same OS works without change/recompile for RamBlade, TriBlade and RamBlade3 hardware providing you use the shipped 6.5MHz xtal. Recompiling is only required for just the one _OS.spin file for a hardware change (_hwdef.spin).
This OS can perform DIR and MAP (DIRCPM and MAPCPM) on our CPM HDD files on the SD card from the OS (FAT). Shortly I will be releasing programs to copy to and from the CPM HDD files to FAT16/32. The OS can run the ZiCog emulations which can return to the OS by executing HALT at the CPM prompt.
OBC: Schematics for the RamBlade & TriBlade are posted on their respective threads. However, I use all available pins to interface the 512KB SRAM, leaving only 2 pins for serial to another prop.
BTW RamBlades are still available. TriBlades are no longer available (pcbs were way too expensive) but I do have a replacement design almost ready to go.
I created those disks in the first place. Initially I created 32MB disks in the hope that we could use them. Alas, we can only use the first 8MB so what you are seeing is just the space allocated to the file, not the actual disk size. Providing Drac is using what we setup, the disks should be 6xMB then two other small ones (cannot recall the sizes).
Trying my luck to get COBOL running on a Propeller I stumbled over this quite old thread.
After reading all the 40 pages I am stumped. In another thread @Heater told me to look for @Pullmoll's Z80 emulator, but sadly @Pullmoll is MIA since a while. So ZiCog seems to be the only existing Version where I can hope that there might be some help out here.
But as far as I understood the latest code runs on @Clusso99's Triblades, not longer available as Hardware. It seems that his newest Ramblade(?) is still able to run CP/M but it looks like there is not any active development on the CP/M thing anymore.
In this thread here there was some talk about using PropGCC XMM drivers with caching to use serial RAMs instead of pin-eating parallel ones, but it looks like this never happened.
I still find this very intriguing to run CP/M on a Propeller because of all the software still available for CP/M.
Sadly @Heater stated he is done with writing emulators on the P1 and the P2 is still not out yet. @Pullmoll has vanished and even @RossH seems to have left. Besides the C3 there is no Parallax board out supporting external RAM, and the C3 is sort of untypical with that SPI switching of stuff attached to the SPI buss.
I somehow dare to say that the P2 is near completion - it is near completion since years, but this time it looks pretty good and I am hoping to see some 'chipmas' next year.
With HUBEXEC instead of LMM/XMM and 512KB of RAM it might be possible to run a Z80 based CP/M subsystem on a 'standard P2' and have still COGs and Pins free for other things.
So how big are the chances that the then active actors @Heater., @Clusso99, @Dr_Acula, (can anybody still reach @Pullmoll?) would be willing to do this?
Me, myself and I are sadly to stupid to even understand most of the code I looked at especially @Pullmoll's PASM), and up to now I still can not run any emulator-CP/M versions I found on any of the Propeller boards in my possession.
So I have not seen a CP/M prompt since 25++ years and might be disappointed, but I still think it is a endeavor worth to try.
So my Christmas present for myself this year will hopefully be a packet from @Clusso99 containing a Ramblade(?) with a runnable CP/M 2.X on it. At least I am still hoping to buy one. Maybe January, for my Birthday since I am quite broke now.
Fixing up and moving into a new house takes away all my Propeller-time and all my money since a couple of month now, but in December I will be done with it and have time to play again.
I make the RamBlade to order. I seem to get an order every few months. Perhaps if I was more actively promoting them I would see more sales.
I had intended to make an add-on board to plug into the P8XBlade2 to make a RamBlade (just like I did for the CpuBlade+MemBlade=RamBlade3) but just haven't got around to it - too many other things to do
I'm afraid I'm not going to be much help here. Time is tight, many other things to do. Unless I suddenly get the urge to dig out my backups and remind myself how it all fit together.
The first time I saw the CP/M prompt from the Prop it ran entirely in 16K of HUB memory, or was it 24 I forget. The display was 2 line LCD panel. Magic moment. At that time it only emulated the 8080 so was small and fast. Sometimes I think I should have stuck with that.
If anyone can has a SPI RAM solution that it could use that might just be the inspiration I need....
I'm afraid I'm not going to be much help here. Time is tight, many other things to do. Unless I suddenly get the urge to dig out my backups and remind myself how it all fit together.
The first time I saw the CP/M prompt from the Prop it ran entirely in 16K of HUB memory, or was it 24 I forget. The display was 2 line LCD panel. Magic moment. At that time it only emulated the 8080 so was small and fast. Sometimes I think I should have stuck with that.
If anyone can has a SPI RAM solution that it could use that might just be the inspiration I need....
The C3 has two SPI SRAM chips on it. Also, you can try this:
The MGA board is 70 dollars. I might as well run CP/M on my 10 dollar STM32 F4 board. Or what about a 2 dollar ESP whatever WIFI module?
I don't mean to be so negative but this is far removed from my early start with buying a 10 euro DIP Prop, welding it to a proto board, hooking up and SD and starting hacking on an emulator.
Open source hardware & software design
Dual high-current 1.5 A, 3.3/5 V voltage regulators with heavy filtering
VGA port with multiplexing logic to reuse IO’s
RCA Video/Audio ports for NTSC/PAL composite video
PS/2 port for keyboard or mouse
1 MB SPI FLASH memory
2-channel Microchip MCP3202 SPI A/D converter with 12-bit resolution (2) Microchip 32K x 8 bit SPI SRAMs
MicroSD card w/SPI interface
(4) 3-wire servo port headers to directly drive servos from the Propeller
Ultra-compact credit-card–sized PCB footprint
Power requirements: 7.5–12 VDC, 300+ mA 2.1mm center-positive supply; OR power via high-power USB, hub port preferred
Communication/Interface: USB, GPIO, microSD card
Dimensions: (without tabs) 3.0 x 2.175” (75.9 x 55.2 mm)
Operating temp range: -40 to +185 °F (-40 to +85 °C)
The MGA board is 70 dollars. I might as well run CP/M on my 10 dollar STM32 F4 board. Or what about a 2 dollar ESP whatever WIFI module?
I don't mean to be so negative but this is far removed from my early start with buying a 10 euro DIP Prop, welding it to a proto board, hooking up and SD and starting hacking on an emulator.
I think Andre' LaMothe will still be selling the C3 even after Parallax no longer has any stock. However, his price is $99 I believe.
You can always take your old 10 Euro DIP Prop and add a SPI SRAM chip to it. That will only cost you a few dollars.
My latest Prop board is a DIP Prop sitting on a proto board designed for the old Raspi format.
All I need is the SPI RAM chip. And the driver with cache of course....
Ummm... I thought you planned to use the SPI SRAM chip for ZiCOG to give it more memory to work with. You could certainly use one of the cache drivers from PropGCC as a starting point but I would think you'd want it optimized to interface with the memory subsystem in ZiCOG. I'm assuming you're not planning on compiling a Z80 emulator written in C, right?
Comments
If you have spare I/O you could connect (or link) another PS2 port (with pullups) on the miniDIn6 pins - there are breakout cables cheap on eBay.
I use a DJ21 with finer pins (from DigiKey). The holes are much smaller.
Have you thought of using an AV4 3.5mm for combined Stereo/TV? I have t/h sockets if you require some and the cables to 3 RCAs are cheap on ebay. Use the AV pinout, not iPhone - I can give you the details if reqd.
I'd checked with available Digital Research's references (most CP/M 1.4, 2.0 and 2.2 Interface Guides) and the above cited file lenght limit of 256k only applies to CP/M 1.4.
Starting from CP/M 2.0 the record numbering was expanded: the last three bytes of the FCB can hold a number from 0 to 65535 in the two least significant bytes, overflowing to the third one only once.
This allows for 65,536 records of 128 bytes to be addressed by any FCB, or 8,192 kBytes as the maximum file lenght.
Back in the days CP/M was coded (end of 70's thru 80's) there was no such things as big capacity linearly addressable midia (at least not for our budgets, mere mortals) and thus there are many issues when dealing with hardware/software blocking and deblocking algorytms to make fully and optimized use of hard drives.
Today's SD's and memory disks easy things a lot.
Yanomani
That would make sense, as Zaks' book was written about the time things were transferring from CP/M 1.4 to 2.2. That also solves a puzzle where some books reference the last digits of the FCB being 2 bytes and some say 3. I could never work out what the third one was for as it was always zero, and I guess that was because all the files I looked at were under 256k.
Thanks for answering this!
I used CP/M 2.2 around 1983-5 with Apple /// and Microsoft Z80 card, plus a Corvus 5MB HDD. The drives were unreliable if powered up and down so they were left powered 24/7.
To do experiments with the bdos I need a simulator. And in the big upgrade from winXP to Win8, Visual Studio needed upgrading, and it seems my nifty code for talking directly to the SIMH no longer works. So I can't use the SIMH for rapid compilation.
Not sure the SIMH could quite do everything here anyway as one needs to hook into it in multiple places. So I have been writing a Z80 simulator in vb.net
I took an existing one written vb6 and heavily modified it. Not quite finished at the moment but you can get the general idea with the attached code. It is not optimised by any means (eg using the bit patterns to do jumps) but in general terms;
How on earth did you get this to fit in a Propeller??!!
That is a heroic effort what with vb.net running on the CLR and all that. I would have said you were crazy but then I remembered a story:
Someone was wanting to write an emulation of some old glass terminal in Java. All it had to do was interpret the control codes coming in and move the cursor around the terminal window, change text colours etc. Normal VT100 emulation kind of stuff.
Problem was they tried and tried but they could not emulate every little corner case of the terminal and their displays were never quite right.
Then they had an idea: We have the binary dump of the ROMs of the original terminal which used a 4040 or 8080 CPU. Lets's write an emulator for that processor in Java, emmbed it in our terminal software and have it do the work for us.
Bingo it worked! Every little bug in the original device being recreated perfectly.
But, surprise, surprise the CPU emulator, written in Java, running the termial ROMs code was faster than their straight Java terminal emulation!
No idea about that. If I remember you can talk to SIMH via telnet. Is that what you were doing? I'm sure that will still work.
With a lot of help from Cluso and others:)
Thank you for your clarification of maximum CP/M 2 file and disk sizes. That is in accordance with my understanding of the docs I found a few years back.
The Later versions of ZiCog use the maximum 8MB sized disks. No floppy disks.
Can't remember if we can drop in as many as 16 of those disks currently but I do remember experimenting with that and it eats up too much CP/M RAM for my taste.
Since I'm a curious one by nature, following the thoughts expressed in the threads and trying to aggregate some useful information became a very joyful and gratifying activity.
I wish to thank you all (and your posts, for sure) for giving me the opportunity of doing this.
The work you and your colleagues have done, bringing to the Propeller world a functional Z80 is outstanding.
Z80's were the third CPU that I have learned in my life. I love to revisit them.
And in my to do list is always pending a deep dive in the second O.S. that i'd put my hands on, and whose taste still persists more than three decades since the very first sip.
Studying this thread gives me opportunity to satisfy both needs.
Yanomani
Thanks. Do have a search of the forums for even more Z80 madness. There is also the qz80 emulator from PullMoll. He even got all the z80 instructions working. ZiCog is still missing a few (Must get round to fixing those). Luckily those instructions are almost never used in CP/M software.
Question, what is the possibility of getting a solution which supports Wordstar running on a Quickstart/PMC with 128k SRAM chip?
Attached is a modified version of the 32k SRAM driver whichs supports the 128k chips, created by one of the Propellerpowered forum users.
I'm just now getting to remind myself how all this works. It's sounds quite doable though.
Thanks
Jeff
I say "in theory", because the code hasn't been written yet. The existing hardware is lots of latches and a parallel sram chip. But the boffins over on the C forum have shown that the performance of slow serial ram but with caching can be superior to parallel ram.
I think one reason no-one looked at the serial ram back 3 years ago was that at the time, those chips only had 32k. But there is now a 128k serial ram chip which is twice what you would need for zicog.
What is needed is a fusion of the cache code and the zicog. Then this whole thing could be done with one propeller and an 8 pin chip.
In terms current working minimum schematics the last ZiCog versions put out by me were running on the middle Prop chip of Cluso's TriBlade board.
See for example page 46 of this thread (zicog_cpm_lmm.zip) I'm sure Cluso can supply the schematic of that.
Cluso also has it running on his tiny RamBlade and Dr_A has his own solutions.
I guess it is time to up grade all of this to more modern solutions with readily available boards and RAM setups. A simple serial RAN solution would be great.
What are the best options now?
This OS can perform DIR and MAP (DIRCPM and MAPCPM) on our CPM HDD files on the SD card from the OS (FAT). Shortly I will be releasing programs to copy to and from the CPM HDD files to FAT16/32. The OS can run the ZiCog emulations which can return to the OS by executing HALT at the CPM prompt.
OBC: Schematics for the RamBlade & TriBlade are posted on their respective threads. However, I use all available pins to interface the 512KB SRAM, leaving only 2 pins for serial to another prop.
BTW RamBlades are still available. TriBlades are no longer available (pcbs were way too expensive) but I do have a replacement design almost ready to go.
from the boot in case it helps.
After reading all the 40 pages I am stumped. In another thread @Heater told me to look for @Pullmoll's Z80 emulator, but sadly @Pullmoll is MIA since a while. So ZiCog seems to be the only existing Version where I can hope that there might be some help out here.
But as far as I understood the latest code runs on @Clusso99's Triblades, not longer available as Hardware. It seems that his newest Ramblade(?) is still able to run CP/M but it looks like there is not any active development on the CP/M thing anymore.
In this thread here there was some talk about using PropGCC XMM drivers with caching to use serial RAMs instead of pin-eating parallel ones, but it looks like this never happened.
I still find this very intriguing to run CP/M on a Propeller because of all the software still available for CP/M.
Sadly @Heater stated he is done with writing emulators on the P1 and the P2 is still not out yet. @Pullmoll has vanished and even @RossH seems to have left. Besides the C3 there is no Parallax board out supporting external RAM, and the C3 is sort of untypical with that SPI switching of stuff attached to the SPI buss.
I somehow dare to say that the P2 is near completion - it is near completion since years, but this time it looks pretty good and I am hoping to see some 'chipmas' next year.
With HUBEXEC instead of LMM/XMM and 512KB of RAM it might be possible to run a Z80 based CP/M subsystem on a 'standard P2' and have still COGs and Pins free for other things.
So how big are the chances that the then active actors @Heater., @Clusso99, @Dr_Acula, (can anybody still reach @Pullmoll?) would be willing to do this?
Me, myself and I are sadly to stupid to even understand most of the code I looked at especially @Pullmoll's PASM), and up to now I still can not run any emulator-CP/M versions I found on any of the Propeller boards in my possession.
So I have not seen a CP/M prompt since 25++ years and might be disappointed, but I still think it is a endeavor worth to try.
So my Christmas present for myself this year will hopefully be a packet from @Clusso99 containing a Ramblade(?) with a runnable CP/M 2.X on it. At least I am still hoping to buy one. Maybe January, for my Birthday since I am quite broke now.
Fixing up and moving into a new house takes away all my Propeller-time and all my money since a couple of month now, but in December I will be done with it and have time to play again.
Enjoy!
Mike
I had intended to make an add-on board to plug into the P8XBlade2 to make a RamBlade (just like I did for the CpuBlade+MemBlade=RamBlade3) but just haven't got around to it - too many other things to do
good to know, so please make one for me, no need to hurry but I would really like to have a Propeller board able to run CP/M.
Please PM me price and Paypal address.
Enjoy!
Mike
I'm afraid I'm not going to be much help here. Time is tight, many other things to do. Unless I suddenly get the urge to dig out my backups and remind myself how it all fit together.
The first time I saw the CP/M prompt from the Prop it ran entirely in 16K of HUB memory, or was it 24 I forget. The display was 2 line LCD panel. Magic moment. At that time it only emulated the 8080 so was small and fast. Sometimes I think I should have stuck with that.
If anyone can has a SPI RAM solution that it could use that might just be the inspiration I need....
https://mghdesigns.com/propeller/dnartc.html
It doesn't come with a SPI SRAM but you can replace the flash chip with SRAM if you want.
The MGA board is 70 dollars. I might as well run CP/M on my 10 dollar STM32 F4 board. Or what about a 2 dollar ESP whatever WIFI module?
I don't mean to be so negative but this is far removed from my early start with buying a 10 euro DIP Prop, welding it to a proto board, hooking up and SD and starting hacking on an emulator.
Under details, it mentions RAM
:
Open source hardware & software design
Dual high-current 1.5 A, 3.3/5 V voltage regulators with heavy filtering
VGA port with multiplexing logic to reuse IO’s
RCA Video/Audio ports for NTSC/PAL composite video
PS/2 port for keyboard or mouse
1 MB SPI FLASH memory
2-channel Microchip MCP3202 SPI A/D converter with 12-bit resolution
(2) Microchip 32K x 8 bit SPI SRAMs
MicroSD card w/SPI interface
(4) 3-wire servo port headers to directly drive servos from the Propeller
Ultra-compact credit-card–sized PCB footprint
Power requirements: 7.5–12 VDC, 300+ mA 2.1mm center-positive supply; OR power via high-power USB, hub port preferred
Communication/Interface: USB, GPIO, microSD card
Dimensions: (without tabs) 3.0 x 2.175” (75.9 x 55.2 mm)
Operating temp range: -40 to +185 °F (-40 to +85 °C)
You can always take your old 10 Euro DIP Prop and add a SPI SRAM chip to it. That will only cost you a few dollars.
http://www.ic0nstrux.com/propc3?filter_name=C3#.WBPAzoMrLcs
His new updated website is:
http://www.nurve.net/
Now we are talking.
My latest Prop board is a DIP Prop sitting on a proto board designed for the old Raspi format.
All I need is the SPI RAM chip. And the driver with cache of course....