I am still using a separate overclocked 104MHz prop with 512KB SRAM and microSD and communicate to another prop via high speed serial for the I/O. I still make the RamBlade and have another version RamBlade3 designed that is slightly slower but puts the serial back to P31/30. Both are small smt boards that usually come assembled. (RamBlade3 pcb still waiting production). I still find this the fastest method.
The Winbond flash RAM chip supplied with the RTC enabled card would be my choice.
I thought Martin actually ASKED about this when he was laying out the board.
But Heater, please understand...
While all through-hole construction would be desirable from a developer's point of view,
(and Lord knows now nostalgic those boards and sockets and wires all are!)
the sub-atomic parts they use today mean orders of magnitude smaller stuff.
One of the reasons I came to this eight ring circus was the possibility of CP/M happening.
Still hoping. But the ez80 is looking better all the time...
Cavelamb,A DIP solution with SMT on a carrier board would be fine :)We have had CP/M running on the Prop under ZiCog and qZ80 emulators for ages.It is my intention to do some cleaning up with ZiCog prior to starting on the PropII version.
cavelamb: you misunderstand the description of a flash chip. this is not ram, but in fact reprogrammable rom. as such it is not suitable for cp/m. the zicog (a z80 emulator) is loaded into cog(s) but the actual cpm code gets loaded into external ram.
i did a t/hole 3 prop design known as the triblade. this pcb was very expensive so ionly ran a small number and there was not enough demand to run another batch of boards. i thenbuilt the ramblade whichwas just the prop with 512KB sram and microsd, all smt on a pcb about 1.2x1.8" iirc. drac then built a number of thole versions with a mix of i/o and sram using latches but latching slows the emulation down quite a bit.
Zicog has been running cpm2.2 on the prop for about 3 years now. it has 8x8MB hard drives mapped on the microsd card. we also ran cpm3 experimentally.
I still look at any bits of scrap kit in the hopes of getting some older memory, so those pesky latches won't eat up space etc.
@ Heater.
I thought of you the other day, as I was fishing about in the innards of some scrap I came across a chip that I didn't recognize, so I looked up what a IMST225 (or 255?) was. Thats the first Transputer I have ever seen/touched (but that does't give you any excuses to go on about that X**s stuff again!).
cavelamb: you misunderstand the description of a flash chip. this is not ram, but in fact reprogrammable rom. as such it is not suitable for cp/m. the zicog (a z80 emulator) is loaded into cog(s) but the actual cpm code gets loaded into external ram.
I think what I'm getting at here when I ask for minimal pin usage and DIP is that I think there are many people out there who might like to give Z80 and CP/M on the Prop a try but it's not worth their effort to get a special board with static RAM or whatever. If there was a dead simple way of attaching RAM to any existing Propeller board then it would be a much easier proposition for a quick look-see.
I think what I'm getting at here when I ask for minimal pin usage and DIP is that I think there are many people out there who might like to give Z80 and CP/M on the Prop a try but it's not worth their effort to get a special board with static RAM or whatever. If there was a dead simple way of attaching RAM to any existing Propeller board then it would be a much easier proposition for a quick look-see.
Is SDCard a requirement to run CP/M? If not, I know of an SDCard based SRAM solution.
CP/M needs at least 64k bytes of RAM to be useful.
Then it needs a "disc" to load from and use as a file system. ZiCog boots from 8MB "hard drives" and can use 8 such drives.
All those drive images can be on SD card.
I think what I'm getting at here when I ask for minimal pin usage and DIP is that I think there are many people out there who might like to give Z80 and CP/M on the Prop a try but it's not worth their effort to get a special board with static RAM or whatever. If there was a dead simple way of attaching RAM to any existing Propeller board then it would be a much easier proposition for a quick look-see.
I remember some of it now, the address counter chains and all...
The dracblade uses 12 prop pins and a 512k SRAM. It takes 20 pasm instructions to fetch one byte. There are better solutions!
One is the SRAM driver for the touchscreen that Average Joe and I built. This uses lots of 161 counters and can fetch two bytes in 4 pasm instructions. So that is 10x faster. The problem is that the board is quite complex and large, and it uses up all the prop pins so the only I/O you have is via the I2C bus.
I wonder if we could brainstorm cache drivers using the new SPI SRAM chips that Jazzed touched on in post #1148?
Quick audit of cogs. One for Spin. One for keyboard. Two for VGA. One for SD card. One for Serial. Something like that anyway. For simplicity's sake we want one spare cog dedicated to running a cache driver.
Keep things in self contained modules. So the SD card driver uses existing code and fetches blocks of 128 or 512 bytes and puts them in hub. The keyboard collects bytes and puts them in a buffer. Ditto serial drivers. VGA is like a serial monitor, possibly with VT100 codes, but to start with, just simple things like line feed and back space and carriage return.
The cache driver lives in a cog and is built on a SPI driver. It checks a hub location for cache requests, when it detects one, it goes and fetches a block of data and places it in hub, and clears a flag to say the data is now available.
The Z80 emulation lives in another cog. It reads or writes bytes in a 64k memory space. One could compress all the read and write data into one long. 16 bits for the 64k address. 8 bits for data. One bit for read or write. One bit to say 'I want this data' which the cache driver processes, and when the data is valid, that bit is cleared.
Complexities...
The Z80 emulation won't fit in a cog. An 8080 one will and maybe there are advantages to just working with 8080? Perhaps have a special code for the DAA that goes out to Spin to solve that?
The reason Z80 gets complicated is that it needs LMM to run. And LMM needs another cog, and I think that means we are out of cogs??
Pullmoll got around this problem by rewriting the entire thing in Pasm. That got rid of the Spin and freed up a cog. But giving up Spin is a high price, because so much code has to be redone - eg the SD driver, keyboard, VGA etc. Esp the SD driver.
So my inclination would be to go for just 8080, put DAA and any other rare but complicated instructions into Spin, use standard Obex objects for all the SD/Keyboard/VGA, and bolt on a cache driver and a single Microchip SPI serial ram.
My reason for this is that it opens up the whole Zicog and CP/M to the masses because you don't need any special hardware. Buy any Propeller board that has an SD card, and add one 8 pin chip.
So, what about using a QuickStart with a VGAPlus board, i.e. Jeff's Pocket Mini Computer? It has a microSD option, and a socket for SRAM. I have a 32KB Microchip SRAM chip in mine (that's the current VGAPlus setup for PMC w/extended RAM), but maybe it would be a feasible target if or when it's possible to use the larger 128KB variant instead? I have no idea how fast this SRAM can be accessed though.
Tor, that might be the perfect platform! All the hardware is done. Just need to change the 32k chip to a larger one (are Microchip sampling these yet?)
The speed may not matter. All the experiments the C boffins have done seem to conclude that cached slow ram is faster than non cached parallel fast ram.
Dr_A,
I'm a bit too tired to think about all this at the moment but:
1) The LMM in ZiCog does not need another COG. ZiCog has an LMM kernel built in, it's just a tiny loop after all.
2) So..putting the DAA and such into Spin is not required.
3) I'd quite like to make an 8080 only version. It's not just a case of ripping out lots of op code handlers though, the 8080 sets some flags differently.
4) I've often thought about ripping out all the FAT file systems stuff. It's only ever used to find the CP/M disc images and then sits there wasting space. There must be a better way to do that. Besides it kind of offends my sensibilities to have a FAT file system in a CP/M machine!
5) I'd quite like to replace all the Spin with C. Perhaps that's a step to far though.
Martin's Propeller-Platform compatible Propeller-DNA Board with SDCard and optional RTC has a DIP8 socket with connections for all 6 DIP8 IO pins for Quad-SPI. A second DIP8 socket allows for sharing SDIO with the SRAM in single bit SPI mode given an appropriate driver (pins configurable). The board can also be powered via a wall-wart, terminal block, or the USB port.
heater: I have worked out the whole CPM fat file workings. It is not quite like the specs say, but I have it working and that's all that matters
My PropOS (works with FAT16/32 files) can launch ZiCog (and therefore CPM 2.2) and return again when CPM is done (by issuing the HALT program/command). File transfers between FAT16/32 and out CPM file system is almost complete and ready for testing.
I have seen reference that CPM 2.2 can only use a maximum of 8MB hard disks. However, using the 4K blocks (as we do with the 8MB disks) I cannot see why we cannot make a HDD DPB for 32MB drives. Is there something I am missing? We have plenty of space on SD/microSD cards for 8x 32MB HDDs.
Do you have the source for the BIOS/BDOS we are using with ZiCog?
heater: I have worked out the whole CPM fat file workings. It is not quite like the specs say, but I have it working and that's all that matters
My PropOS (works with FAT16/32 files) can launch ZiCog (and therefore CPM 2.2) and return again when CPM is done (by issuing the HALT program/command). File transfers between FAT16/32 and out CPM file system is almost complete and ready for testing.
I have seen reference that CPM 2.2 can only use a maximum of 8MB hard disks. However, using the 4K blocks (as we do with the 8MB disks) I cannot see why we cannot make a HDD DPB for 32MB drives. Is there something I am missing? We have plenty of space on SD/microSD cards for 8x 32MB HDDs.
Do you have the source for the BIOS/BDOS we are using with ZiCog?
Sapieha: No, I don't think it is the buffer size. The buffers are only 128 bytes unless the sector size is changed. Currently we have 8MB disk files configured with 4KB blocks. The AL can address up to 32MB of 4KB blocks. Perhaps there is a fat map that may have issues but I am just not sure. As heater made us the 8MB DPB I am hoping he knows or else knows who to ask. I have seen references to larger disk drives mentioned with CPM2.2 but cannot locate who did this and how.
Studying Digital Research's CP/M 2.2 Alteration Guide and one of the many CP/M 2.2 source codes found on the Web it was possible to figure the following information:
-Maximum file size = 8192 kB.
-Maximum logical disk size = 8,192 kB (plus directory information and file allocation tables).
-Maximum number of logical disks = 16 (A thru P).
-Useable physical disk = (16 x 8,192 kB) = 131,072kB = 128 MB of file contents (plus directory information and file allocation tables).
-The boot drive must have a reserved space at the beginning for the boot code and O.S. usage. More study can be done to account for every bit of information needed.
Thanks Yanomani. I have not had time to check all your details but here are some comments...
(I have corrected what might be ambiguities)
- Maximum logical disk size is a count of (offset tracks reserved for cpm + no of directory entries + filespace)
-- this space is made up of number of blocks (allocation blocks) and in our case of 8MB HDD they are 4KB so we have 2048 * 4KB = 8MB
--- 2048 = 11 bits and uses a mask of $3FF (0-2047)
---- In our 8MB HDD we reserve 6 tracks for cpm, and each track is 4KB (same as our block size)
---- We also have 1024 DIR entries of 32B = 1024*32/4KB= 8*4KB blocks
---- So we have 2048-6-8=2034*4KB blocks for filespace
---- CPM uses block numbers (for AL[0..7] on the DIR entries) beginning with the DIR base (i.e. in our case +6 from the start of the HDD)
We have 8 HDD of 8MB allocated in our CPM BIOS/BDOS. Heater prepared the BIOS/BDOS.
Let me get back to you an that BIOS question. Just now my ZiCog efforts seem to have sprawled over a few machines and I have to figure out what versions are what. It's all been stirred up by computer upgrades, disc failures and so on over time.
Re: Large disks. If I remember correctly we can easily change the disk geometries by tweaking the File Control Blocks (FCB) or whatever they are called. These are actually defined outside of the BIOS so no changes are required there, The tables are actually initialized in Spin code.
There are two problems with this:
1) I never did understand very well how those FBC's work. Setting the fields requires some careful calculation.
2) The biggie: The bigger the disks the more of CP/M's memory space gets eaten up at run time to manage them. I remember that at some point I thought the trade off to get bigger than what we have was not worth it.
On the other hand it does appeal to me to setup the biggest possible disks and the most of them. Just so we can say we have the biggest CP/M storage system the world has ever seen:)
It should be possible to test any different configurations from the SIMSH Z80 simulator before moving to the Prop.
Let me get back to you an that BIOS question. Just now my ZiCog efforts seem to have sprawled over a few machines and I have to figure out what versions are what. It's all been stirred up by computer upgrades, disc failures and so on over time.
What disk failures! PCs running *nix never fail. (well at least less than windoze!) I feel your pain. I have my prop code spread over 2 laptops and the backup external drives. At least I have lots of history comments and revision codes and dates - a lesson passed on by a colleague when I started coding in the very early 70's .
Re: Large disks. If I remember correctly we can easily change the disk geometries by tweaking the File Control Blocks (FCB) or whatever they are called. These are actually defined outside of the BIOS so no changes are required there, The tables are actually initialized in Spin code.
There are two problems with this:
1) I never did understand very well how those FBC's work. Setting the fields requires some careful calculation.
2) The biggie: The bigger the disks the more of CP/M's memory space gets eaten up at run time to manage them. I remember that at some point I thought the trade off to get bigger than what we have was not worth it.
I now understand the DPBs so that is no longer a problem. I just was not sure what needs to be changed to support larger DPBs. I have built a spin program that maps the directories and files usage of the blocks, and I can read and write files to the CPM HDD directly from spin without CPM.
I would think that 2048 DIR entries (currently 1024) would be fine and we should keep 4KB blocks although we could increase that to 8KB or 16KB blocks. We should keep 128 byte sectors (a CPM2.2 requirement?). The track size should be the same as the block size to keep maths simple.
On the other hand it does appeal to me to setup the biggest possible disks and the most of them. Just so we can say we have the biggest CP/M storage system the world has ever seen:)
Would be nice - there is plenty of space on those 2GB SD cards, let alone the larger ones. We have a max of 8 HDDs but I saw elsewhere that 16 drives was CPMs max. Only reason to change would be to create the biggest CPM machine.
It should be possible to test any different configurations from the SIMSH Z80 simulator before moving to the Prop.
Oh, yes. Having spent decades working on assortment of military and avionic projects where every byte is version controlled and traced up the wazzo.Where everything is designed, documented, previewed, reviewed, tested until you are blue in the face. You might wonder how I got into such a mess.
I don't know. Somehow things have been spread over a few PC's and laptops. Backups and copies all over the place. Machines have come and gone and now I have a huge binary soup of projects. I'm drowning in chaos.
But, I will save myself. Luckily there is now Git. The first version control and source code management system I can bear to use. And I have had to use many. In fact it's even a joy to use. Want to have snap shots of every version you have ever made of a project? It's there. Want to have different branches of a project for trying out new features or bug fixes? It's there. Want to merge bits of code from place to place easily?, It's there. Want to have many copies of your project in different places, for back up at least? It's there. Want to collaborate easily with other developers? It's there. And all in a way that does not drive you nuts trying to maintain it all.
All my new projects are in github.com. There is even a, currently empty repository for ZiCog.
Cluso,
Thanks for all clarifications.
Back in 1983 i'd studied all the docs available on my first Superbrain and its CP/M 2.2 O.S. It was good to revisit part of the available docs on the Web.
As for the total drive number limit it belongs to Function 14 (Select Disk) operating limits where a value of 0 selects the current drive (the previous selected one from any previous disk operation) and a value in the range of 1 to 16 expressly selects one of the possible disks (A thru P).
As for the logical record lenght of 128 bytes, I believe it's historicaly connected to IBM System/32.
In sequential file access operations, it's easy to know if you are reading past the end of file since the file lenght itself establishes a limit. One can append more data (sequentialy) and grow it up till the maximum file size is reached.
Things get complicated a bit in random file operations, because one must logically known if a specific record was writen (initialized) before or not.
Thats the reason for the existence of fewer error code significances in Function 20 (Read Sequential) where a return code of 00H signifies a successful operation and a nonzero return code means no data exists (e.g end-of-data occurs).
In Function 33 (Read Random) there are seven possible return codes:
00H - Successful operation
01H - Reading unwritten data
02H - (not returned in random mode)
03H - Cannot close current extent
04H - Seek to unwritten extent
05H - (not returned in read mode)
06H - Seek past physical end of disk.
Error code 06H is very interesting since it shows how easy was to setup a file proccess that explores the harware limits of the available disk drives at the time the O.S. was coded.
I believe SuperCalc and other spreadsheet apps from that era explored random file operations a lot.
I hope some of the above information could help a bit.
-Maximum file size = 8192 kB.
-Maximum logical disk size = 8,192 kB (plus directory information and file allocation tables).
-Maximum number of logical disks = 16 (A thru P).
-Useable physical disk = (16 x 8,192 kB) = 131,072kB = 128 MB of file contents (plus directory information and file allocation tables).
-The boot drive must have a reserved space at the beginning for the boot code and O.S. usage. More study can be done to account for every bit of information needed.
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.
We might now describe that as a limitation! I personally think there are some other limitations as well, such as the need to create disk images which adds another step moving data around. Is rewriting the BDOS allowed? I'd like to think so, and I think it is in the spirit of CP/M that it can be recompiled with a new BIOS, and/or a new BDOS, and it can still be called CP/M.
This is partly in response to a PM from Cluso99, and partly something I've wanted to do anyway to improve the Zicog.
The
BDOS has entry points that include the following primitive operations, which the program
accesses:
-SEARCH looks for a particular disk file by name.
-OPEN opens a file for further operations.
-CLOSE closes a file after processing.
-RENAME changes the name of a particular file.
-READ reads a record from a particular file.
-WRITE writes a record to a particular file.
-SELECT selects a particular disk drive for further operations.
These are not that different to the handles that FSRW and Kye's program gives us. We can get technical with the actual BDOS call numbers, but they are not much more than this list. Sequential read/write gets/writes the next 128 bytes. Random read/write puts the data in the correct place.
The error codes Yanomani quotes are extremely useful. What I would like to do is create some Spin code to fake all those error codes. I don't think they are too different to the error codes FSRW and Kye's code returns anyway. You want to know if out of disk space, the file is not created yet, whether there was a successful operation etc.
The whole point of this is to read and write files directly to and from an SD card.
So - disk size is now the SD card size.
Max file size is still (probably) 256k.
Looking at the FCB
Byte 0 = entry type which is the drive code in CP/M 2.2. For an SD card, that would usually be 0 (drive A)
Byte 1-8 = the file name
Byte 9-11 = the file extension
Byte 12 is the file extent and I'll describe below what I think this does
Byte 13 and 14 are not described in Zaks' book
Byte 15 is the record count - 0 to 127
Byte 16-31 is the disk allocation map. I propose discarding this and letting the SD card handle this.
Byte 32 is the next record number
Byte 33-35 is the record number for random read/write
Re byte 12, what I think CP/M does is that it stores the file name and extension FCB and that will store up to 16k of information. The FCB contains the disk map where all the actual data exists. What I think happens is that if you need another 16k, it creates a new FCB with the same file name and extension, and now sets byte 12 to 1, and so on for each 16k block of data.
I think it should be possible to move a lot of this over to Spin. CP/M sends command hex 16 - make a file, and Spin makes a file. The filename is in the FCB. BDOS commands like make, open, close, rename, delete, all map directly to FSRW commands. More complex things like "fetch random record n from extent x for the filename aaaaaaa.bbb" still can be translated fairly easily to Spin and can return the appropriate error codes like "the record number is past the end of the file".
I think the data the CP/M BDOS puts into the FCB regarding the actual record locations can largely be ignored. Only diagnostic programs are really going to be looking for that. Most programs are just interested in the data, eg Wordstar is opening a file and grabbing text until the end of the file.
My other cool idea for Zicog is to rewrite it for serial sram, so it only takes 4 pins, and to borrow the caching algorithms the GCC boffins are using. I think it would actually run faster than the parallel ram code - eg the dracblade which was 20 pasm instructions to fetch one byte from external mem, maybe this can be a few instructions to check if this is a cache it or miss and most of the time it will be a hit so the data will be fetched from hub ram.. Could it be as few as 5 pasm instructions most of the time?
I'm not so keen on ripping out the BIOS and BDOS. I'd actually prefer to get rid of all the FSRW stuff, and just have a native CP/M machine like we had originally.
Ideally ZiCog should be rearranged a bit so that it is just a Z80 engine. Then one could take that and do whatever with it. But those projects would not be ZiCog.
I was also wondering about the serial memory solutions that have sprouted up since ZiCog started. I get the feeling the end result might be slower but if we can do it easily with a lot less pins I'd go for it.
I'm not so keen on ripping out the BIOS and BDOS. I'd actually prefer to get rid of all the FSRW stuff, and just have a native CP/M machine like we had originally.
You are right. How could I consider ripping the heart out of CP/M?
By way of penance I have designed a little board with a 128k serial ram. It ends up with 8 propeller pins free. Has audio, keyboard, SD card, VGA, TV. The board is 10x10cm as this size is a good price for Seed Studios (around $4 each)
How would it work?
I think the boffins over on the N8VEM group have some SD code working for a real Z80, so either this could be ported or the FSRW could be translated, or one could gradually move more things from pasm to Z80.
One concern might be that if the SD driver code got too big - bigger than the usual BDOS. If this happened, could one think about two banks of 64k sitting in the serial ram, and moving all of CP/M into the high bank? Then the TPA would be almost the full 64k, and there would be plenty of room for SD driver code. Plus - the more code you move from spin into the zicog, the more hub ram gets freed up for the display.
My plan all along was to use the BDOS and BIOS from the SIMH Altairz80 project unchanged. It's nice to borrow stuff like that as we don't have to do any work! And as SIMH fixes bugs or makes new versions we can adopt them with no effort. Importantlay it means things can be tested gainst SIMH on a PC and then moved over to ZiCog.
Currently the ZiCog BIOS is the same as the one used in the SIMH Altairz80 simulator. It does not need any SD or other hardware disk driver as it simply collects the disk blocks from the SIMH simulator (written in C). In the ZiCog case it uses the SIMH interface to get disk blocks from the SD driver running in another COG. We could replace the block driver with anything else if we like with no change to the BIOS.
(Edit: Thinks, thinks...perhaps that's not quite true, we tweaked the BIOS to use 128 byte sectors instead of the weird 137 or whatever it was in Altair.)
ZiCog does have FSRW in there. Only to use the FAT file system to find where the CP/M disk images are at start up. After that it is not used. I'd be quite happy to remove FSRW and find the disks another way.
The boot loader we did rewrite. Had to be done to boot from 128 byte block disks.
I'm all for people taking the ZiCog engine and using a heavily modified CP/M with some BDOS emulation or whatever but they world be different projects.
I like the serial RAM board.
I have to find some "quality" time for getting to know ZiCog again, I hardly remember what it looks like. Especially as we have the Prop II comming up.
Comments
Easiest because one can simply buy the board, populate the socket and run it.
http://mghdesigns.com/propeller/mgh-designs/dna.html
It has two sockets for external memory - you choose.
details of the board are at: http://mghdesigns.com/wiki/dna:start
The Winbond flash RAM chip supplied with the RTC enabled card would be my choice.
I thought Martin actually ASKED about this when he was laying out the board.
But Heater, please understand...
While all through-hole construction would be desirable from a developer's point of view,
(and Lord knows now nostalgic those boards and sockets and wires all are!)
the sub-atomic parts they use today mean orders of magnitude smaller stuff.
One of the reasons I came to this eight ring circus was the possibility of CP/M happening.
Still hoping. But the ez80 is looking better all the time...
i did a t/hole 3 prop design known as the triblade. this pcb was very expensive so ionly ran a small number and there was not enough demand to run another batch of boards. i thenbuilt the ramblade whichwas just the prop with 512KB sram and microsd, all smt on a pcb about 1.2x1.8" iirc. drac then built a number of thole versions with a mix of i/o and sram using latches but latching slows the emulation down quite a bit.
Zicog has been running cpm2.2 on the prop for about 3 years now. it has 8x8MB hard drives mapped on the microsd card. we also ran cpm3 experimentally.
@ Heater.
I thought of you the other day, as I was fishing about in the innards of some scrap I came across a chip that I didn't recognize, so I looked up what a IMST225 (or 255?) was. Thats the first Transputer I have ever seen/touched (but that does't give you any excuses to go on about that X**s stuff again!).
My bad. Apologies.
While this is true, there are also 128KB SRAMs available now with SPI or QuadSPI interfaces that should work fine and free up tons of propeller pins.
Is SDCard a requirement to run CP/M? If not, I know of an SDCard based SRAM solution.
Then it needs a "disc" to load from and use as a file system. ZiCog boots from 8MB "hard drives" and can use 8 such drives.
All those drive images can be on SD card.
I remember some of it now, the address counter chains and all...
One is the SRAM driver for the touchscreen that Average Joe and I built. This uses lots of 161 counters and can fetch two bytes in 4 pasm instructions. So that is 10x faster. The problem is that the board is quite complex and large, and it uses up all the prop pins so the only I/O you have is via the I2C bus.
I wonder if we could brainstorm cache drivers using the new SPI SRAM chips that Jazzed touched on in post #1148?
Quick audit of cogs. One for Spin. One for keyboard. Two for VGA. One for SD card. One for Serial. Something like that anyway. For simplicity's sake we want one spare cog dedicated to running a cache driver.
Keep things in self contained modules. So the SD card driver uses existing code and fetches blocks of 128 or 512 bytes and puts them in hub. The keyboard collects bytes and puts them in a buffer. Ditto serial drivers. VGA is like a serial monitor, possibly with VT100 codes, but to start with, just simple things like line feed and back space and carriage return.
The cache driver lives in a cog and is built on a SPI driver. It checks a hub location for cache requests, when it detects one, it goes and fetches a block of data and places it in hub, and clears a flag to say the data is now available.
The Z80 emulation lives in another cog. It reads or writes bytes in a 64k memory space. One could compress all the read and write data into one long. 16 bits for the 64k address. 8 bits for data. One bit for read or write. One bit to say 'I want this data' which the cache driver processes, and when the data is valid, that bit is cleared.
Complexities...
The Z80 emulation won't fit in a cog. An 8080 one will and maybe there are advantages to just working with 8080? Perhaps have a special code for the DAA that goes out to Spin to solve that?
The reason Z80 gets complicated is that it needs LMM to run. And LMM needs another cog, and I think that means we are out of cogs??
Pullmoll got around this problem by rewriting the entire thing in Pasm. That got rid of the Spin and freed up a cog. But giving up Spin is a high price, because so much code has to be redone - eg the SD driver, keyboard, VGA etc. Esp the SD driver.
So my inclination would be to go for just 8080, put DAA and any other rare but complicated instructions into Spin, use standard Obex objects for all the SD/Keyboard/VGA, and bolt on a cache driver and a single Microchip SPI serial ram.
My reason for this is that it opens up the whole Zicog and CP/M to the masses because you don't need any special hardware. Buy any Propeller board that has an SD card, and add one 8 pin chip.
Thoughts?
-Tor
The speed may not matter. All the experiments the C boffins have done seem to conclude that cached slow ram is faster than non cached parallel fast ram.
I'm a bit too tired to think about all this at the moment but:
1) The LMM in ZiCog does not need another COG. ZiCog has an LMM kernel built in, it's just a tiny loop after all.
2) So..putting the DAA and such into Spin is not required.
3) I'd quite like to make an 8080 only version. It's not just a case of ripping out lots of op code handlers though, the 8080 sets some flags differently.
4) I've often thought about ripping out all the FAT file systems stuff. It's only ever used to find the CP/M disc images and then sits there wasting space. There must be a better way to do that. Besides it kind of offends my sensibilities to have a FAT file system in a CP/M machine!
5) I'd quite like to replace all the Spin with C. Perhaps that's a step to far though.
http://mghdesigns.com/propeller/dna.html
http://mghdesigns.com/wiki/dna:start
Microchip 128KB QuadSPI capable SRAM
My PropOS (works with FAT16/32 files) can launch ZiCog (and therefore CPM 2.2) and return again when CPM is done (by issuing the HALT program/command). File transfers between FAT16/32 and out CPM file system is almost complete and ready for testing.
I have seen reference that CPM 2.2 can only use a maximum of 8MB hard disks. However, using the 4K blocks (as we do with the 8MB disks) I cannot see why we cannot make a HDD DPB for 32MB drives. Is there something I am missing? We have plenty of space on SD/microSD cards for 8x 32MB HDDs.
Do you have the source for the BIOS/BDOS we are using with ZiCog?
It is CPM's buffer size that are to small for that --- it reside with 80h to FFH as next address 100H is start of program area
-Maximum file size = 8192 kB.
-Maximum logical disk size = 8,192 kB (plus directory information and file allocation tables).
-Maximum number of logical disks = 16 (A thru P).
-Useable physical disk = (16 x 8,192 kB) = 131,072kB = 128 MB of file contents (plus directory information and file allocation tables).
-The boot drive must have a reserved space at the beginning for the boot code and O.S. usage. More study can be done to account for every bit of information needed.
Could someone confirm those findings?
Sources used:
http://www.nj7p.info/Common/Toys/Software/OS/CPM80-2_2.html
http://www.retroarchive.org/cpm/archive/unofficial/source.html
(I have corrected what might be ambiguities)
- Maximum logical disk size is a count of (offset tracks reserved for cpm + no of directory entries + filespace)
-- this space is made up of number of blocks (allocation blocks) and in our case of 8MB HDD they are 4KB so we have 2048 * 4KB = 8MB
--- 2048 = 11 bits and uses a mask of $3FF (0-2047)
---- In our 8MB HDD we reserve 6 tracks for cpm, and each track is 4KB (same as our block size)
---- We also have 1024 DIR entries of 32B = 1024*32/4KB= 8*4KB blocks
---- So we have 2048-6-8=2034*4KB blocks for filespace
---- CPM uses block numbers (for AL[0..7] on the DIR entries) beginning with the DIR base (i.e. in our case +6 from the start of the HDD)
We have 8 HDD of 8MB allocated in our CPM BIOS/BDOS. Heater prepared the BIOS/BDOS.
Let me get back to you an that BIOS question. Just now my ZiCog efforts seem to have sprawled over a few machines and I have to figure out what versions are what. It's all been stirred up by computer upgrades, disc failures and so on over time.
Re: Large disks. If I remember correctly we can easily change the disk geometries by tweaking the File Control Blocks (FCB) or whatever they are called. These are actually defined outside of the BIOS so no changes are required there, The tables are actually initialized in Spin code.
There are two problems with this:
1) I never did understand very well how those FBC's work. Setting the fields requires some careful calculation.
2) The biggie: The bigger the disks the more of CP/M's memory space gets eaten up at run time to manage them. I remember that at some point I thought the trade off to get bigger than what we have was not worth it.
On the other hand it does appeal to me to setup the biggest possible disks and the most of them. Just so we can say we have the biggest CP/M storage system the world has ever seen:)
It should be possible to test any different configurations from the SIMSH Z80 simulator before moving to the Prop.
I would think that 2048 DIR entries (currently 1024) would be fine and we should keep 4KB blocks although we could increase that to 8KB or 16KB blocks. We should keep 128 byte sectors (a CPM2.2 requirement?). The track size should be the same as the block size to keep maths simple.
Would be nice - there is plenty of space on those 2GB SD cards, let alone the larger ones. We have a max of 8 HDDs but I saw elsewhere that 16 drives was CPMs max. Only reason to change would be to create the biggest CPM machine. I have never run SIMH.
Oh, yes. Having spent decades working on assortment of military and avionic projects where every byte is version controlled and traced up the wazzo.Where everything is designed, documented, previewed, reviewed, tested until you are blue in the face. You might wonder how I got into such a mess.
I don't know. Somehow things have been spread over a few PC's and laptops. Backups and copies all over the place. Machines have come and gone and now I have a huge binary soup of projects. I'm drowning in chaos.
But, I will save myself. Luckily there is now Git. The first version control and source code management system I can bear to use. And I have had to use many. In fact it's even a joy to use. Want to have snap shots of every version you have ever made of a project? It's there. Want to have different branches of a project for trying out new features or bug fixes? It's there. Want to merge bits of code from place to place easily?, It's there. Want to have many copies of your project in different places, for back up at least? It's there. Want to collaborate easily with other developers? It's there. And all in a way that does not drive you nuts trying to maintain it all.
All my new projects are in github.com. There is even a, currently empty repository for ZiCog.
Thanks for all clarifications.
Back in 1983 i'd studied all the docs available on my first Superbrain and its CP/M 2.2 O.S. It was good to revisit part of the available docs on the Web.
As for the total drive number limit it belongs to Function 14 (Select Disk) operating limits where a value of 0 selects the current drive (the previous selected one from any previous disk operation) and a value in the range of 1 to 16 expressly selects one of the possible disks (A thru P).
As for the logical record lenght of 128 bytes, I believe it's historicaly connected to IBM System/32.
In sequential file access operations, it's easy to know if you are reading past the end of file since the file lenght itself establishes a limit. One can append more data (sequentialy) and grow it up till the maximum file size is reached.
Things get complicated a bit in random file operations, because one must logically known if a specific record was writen (initialized) before or not.
Thats the reason for the existence of fewer error code significances in Function 20 (Read Sequential) where a return code of 00H signifies a successful operation and a nonzero return code means no data exists (e.g end-of-data occurs).
In Function 33 (Read Random) there are seven possible return codes:
00H - Successful operation
01H - Reading unwritten data
02H - (not returned in random mode)
03H - Cannot close current extent
04H - Seek to unwritten extent
05H - (not returned in read mode)
06H - Seek past physical end of disk.
Error code 06H is very interesting since it shows how easy was to setup a file proccess that explores the harware limits of the available disk drives at the time the O.S. was coded.
I believe SuperCalc and other spreadsheet apps from that era explored random file operations a lot.
I hope some of the above information could help a bit.
Yanomani
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.
We might now describe that as a limitation! I personally think there are some other limitations as well, such as the need to create disk images which adds another step moving data around. Is rewriting the BDOS allowed? I'd like to think so, and I think it is in the spirit of CP/M that it can be recompiled with a new BIOS, and/or a new BDOS, and it can still be called CP/M.
This is partly in response to a PM from Cluso99, and partly something I've wanted to do anyway to improve the Zicog.
Take a look at the text from the CP/M manual http://www.cpm.z80.de/manuals/cpm22-m.pdf on page
These are not that different to the handles that FSRW and Kye's program gives us. We can get technical with the actual BDOS call numbers, but they are not much more than this list. Sequential read/write gets/writes the next 128 bytes. Random read/write puts the data in the correct place.
The error codes Yanomani quotes are extremely useful. What I would like to do is create some Spin code to fake all those error codes. I don't think they are too different to the error codes FSRW and Kye's code returns anyway. You want to know if out of disk space, the file is not created yet, whether there was a successful operation etc.
The whole point of this is to read and write files directly to and from an SD card.
So - disk size is now the SD card size.
Max file size is still (probably) 256k.
Looking at the FCB
Byte 0 = entry type which is the drive code in CP/M 2.2. For an SD card, that would usually be 0 (drive A)
Byte 1-8 = the file name
Byte 9-11 = the file extension
Byte 12 is the file extent and I'll describe below what I think this does
Byte 13 and 14 are not described in Zaks' book
Byte 15 is the record count - 0 to 127
Byte 16-31 is the disk allocation map. I propose discarding this and letting the SD card handle this.
Byte 32 is the next record number
Byte 33-35 is the record number for random read/write
Re byte 12, what I think CP/M does is that it stores the file name and extension FCB and that will store up to 16k of information. The FCB contains the disk map where all the actual data exists. What I think happens is that if you need another 16k, it creates a new FCB with the same file name and extension, and now sets byte 12 to 1, and so on for each 16k block of data.
I think it should be possible to move a lot of this over to Spin. CP/M sends command hex 16 - make a file, and Spin makes a file. The filename is in the FCB. BDOS commands like make, open, close, rename, delete, all map directly to FSRW commands. More complex things like "fetch random record n from extent x for the filename aaaaaaa.bbb" still can be translated fairly easily to Spin and can return the appropriate error codes like "the record number is past the end of the file".
I think the data the CP/M BDOS puts into the FCB regarding the actual record locations can largely be ignored. Only diagnostic programs are really going to be looking for that. Most programs are just interested in the data, eg Wordstar is opening a file and grabbing text until the end of the file.
My other cool idea for Zicog is to rewrite it for serial sram, so it only takes 4 pins, and to borrow the caching algorithms the GCC boffins are using. I think it would actually run faster than the parallel ram code - eg the dracblade which was 20 pasm instructions to fetch one byte from external mem, maybe this can be a few instructions to check if this is a cache it or miss and most of the time it will be a hit so the data will be fetched from hub ram.. Could it be as few as 5 pasm instructions most of the time?
I'm not so keen on ripping out the BIOS and BDOS. I'd actually prefer to get rid of all the FSRW stuff, and just have a native CP/M machine like we had originally.
Ideally ZiCog should be rearranged a bit so that it is just a Z80 engine. Then one could take that and do whatever with it. But those projects would not be ZiCog.
I was also wondering about the serial memory solutions that have sprouted up since ZiCog started. I get the feeling the end result might be slower but if we can do it easily with a lot less pins I'd go for it.
You are right. How could I consider ripping the heart out of CP/M?
By way of penance I have designed a little board with a 128k serial ram. It ends up with 8 propeller pins free. Has audio, keyboard, SD card, VGA, TV. The board is 10x10cm as this size is a good price for Seed Studios (around $4 each)
How would it work?
I think the boffins over on the N8VEM group have some SD code working for a real Z80, so either this could be ported or the FSRW could be translated, or one could gradually move more things from pasm to Z80.
One concern might be that if the SD driver code got too big - bigger than the usual BDOS. If this happened, could one think about two banks of 64k sitting in the serial ram, and moving all of CP/M into the high bank? Then the TPA would be almost the full 64k, and there would be plenty of room for SD driver code. Plus - the more code you move from spin into the zicog, the more hub ram gets freed up for the display.
Sorry I did not state my position very well.
My plan all along was to use the BDOS and BIOS from the SIMH Altairz80 project unchanged. It's nice to borrow stuff like that as we don't have to do any work! And as SIMH fixes bugs or makes new versions we can adopt them with no effort. Importantlay it means things can be tested gainst SIMH on a PC and then moved over to ZiCog.
Currently the ZiCog BIOS is the same as the one used in the SIMH Altairz80 simulator. It does not need any SD or other hardware disk driver as it simply collects the disk blocks from the SIMH simulator (written in C). In the ZiCog case it uses the SIMH interface to get disk blocks from the SD driver running in another COG. We could replace the block driver with anything else if we like with no change to the BIOS.
(Edit: Thinks, thinks...perhaps that's not quite true, we tweaked the BIOS to use 128 byte sectors instead of the weird 137 or whatever it was in Altair.)
ZiCog does have FSRW in there. Only to use the FAT file system to find where the CP/M disk images are at start up. After that it is not used. I'd be quite happy to remove FSRW and find the disks another way.
The boot loader we did rewrite. Had to be done to boot from 128 byte block disks.
I'm all for people taking the ZiCog engine and using a heavily modified CP/M with some BDOS emulation or whatever but they world be different projects.
I like the serial RAM board.
I have to find some "quality" time for getting to know ZiCog again, I hardly remember what it looks like. Especially as we have the Prop II comming up.