N8VEM + Propeller = PropIO
lynchaj
Posts: 87
Hi!· I just wanted to let the Propeller builders know about the great progress Dave (aka Yoda's) making with the PropIO board for the N8VEM home brew computing project.·
Great job Dave!· Props to Cluso99, James,·and some other Propeller fans too!
http://groups.google.com/group/n8vem/browse_thread/thread/f6cb899ef2965903
Thanks and have a nice day!
Andrew Lynch
Great job Dave!· Props to Cluso99, James,·and some other Propeller fans too!
http://groups.google.com/group/n8vem/browse_thread/thread/f6cb899ef2965903
Thanks and have a nice day!
Andrew Lynch
Comments
As you know, our own (heater, Dr_Acula and I) version of ZiCog on the prop is also progressing well. There are great synergies to be had with the N8VEM group and the ZiCog prop group.
Currently, we are discussing the SD card layout for the CPM/MPM files on the ZiCog and the TriBlade threads and would like them to be interchangeable with the N8VEM format.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Thanks. I need to get back on my Triblade as well. I really would like to see us using 512 byte sectors. I think we can probably do it on the prop side of the disk emulation if necessary. We would gain 4x on reads, we will lose some on writes potentially if they are random. It is pretty simple to do the translation from logical sector to physical block and keep track of what block is currently in the buffer. The only trick on a write is if the block is not in memory you have to read the block and merge the data and write it back out. If the next sector to write is already in the buffer you just update and write it again. I don't think it is too hard to do. I am thinking of doing that on the N8VEM and we can lift the code once I get it to work.
I have been following the work you 3 have been doing and am itching to jump back in and help. Let me know where I can help
Dave
UPENE is tomorrow!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Briel Computers
http://www.brielcomputers.com
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Also, the pocketerm has the very useful function key settings with the menu bar at the bottom of the screen. So if you connect it to a board and you don't know the baud rate of that board (any board really), you can cycle through baud rates until the characters make sense. Other settings could be added to that system with the menu bar at the bottom, eg which version of CP/M, whether to enable hard drives or not. It could mean that multiple ifdefs are not needed as the settings are done by the user. And the pocketerm remembers the settings for next time so you only need to do it once. I guess the idea I'm thinking of is whether more things can be put on the pocketerm, eg support for more serial ports, the cp/m hard drive and floppy drive emulation, the ability to boot in one version of cp/m but load a different version based on a different floppy image etc.
Short term - maybe something similar for a terminal program that goes on blade 1 of the triblade.
Medium term - add this functionality to the N8VEM Prop I/O
Longer term - add it all to a single prop chip emulation that does everything
Long long term, put the whole thing in the Prop II.
Certainly having the propeller on a N8VEM peripheral protoboard enables experimenting with these things.
Post Edited (Dr_Acula) : 8/22/2009 7:43:02 AM GMT
You have done what I had in mind almost two years ago before I got "lazy" and decided to write an 8080 emulation instead of building the hardware. That's been a fun ride but I still have a nostalgic urge to have a real Z80 running so I follow you progress with much interest.
Actually I have an NEC V20 chip stashed away which is an 8088 clone with the ability to also run 8080 instructions. MSDOS and CP/M anyone? Still that's another story.
Yoda: That business about 512 byte sectors has been on the "get round to it one day" list for a long time and yes it does seem to result in a huge speed up as shown by Dr_A. My suggestion is: DON'T DO IT. Don't use the floppy drivers, use the hard disk drivers instead. The geometry of the hard disk drivers can be tweaked to change sector size, sectors per track etc by changing tables in the Spin code.
Now I don't know about the N8VEM CBIOS but ZiCog is using a stock SIMH Altair Z80 BIOS which supports 8 floppy drives (A: to H[noparse]:)[/noparse] and up to 4 hard disks (I: to L[noparse]:)[/noparse]. With a bit of hacking I think that BIOS could be changed to just one (or even none) floppy drives and make them all hard disks with 512 byte sectors.
Down side is that the HD's eat more CP/M memory space, no idea how badly yet.
Sadly I don't think you can support the DMA from the hard drives on N8VEM so our existing hard drive emulation would have to have that removed. Not a big change. Does mean that ZiCog will be faster than the real Z80 when accessing HDs though [noparse]:)[/noparse]
If you still wan to stick with floppies you could live dangerously and used delayed writes. That is when a 128 bytes sector is written update the 512 byte buffer that it lives in but don't write the buffer out to SD immediately. Quite often the next sector written will be in the same 512 byte block so there is some speed gain by not flushing to SD after each write. It's a bit hairy as it increases the risk if corruption if the power fails.
Yoda: Perhaps you can help. There has been suggestions of using drives all the way up to Z: I don't think this is reasonable, as I said each drive eats a bit of CP/M memory, but do you know if CP/M has a limit on the number of drives? I have a feeling it may be 16.
Also. Do you know how to tweak the parameters in the hard disk parameter blocks ? I have not much idea what all those fields mean. We would like 512 byte sectors, and disks as large as possible under CP/M 3.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Vince: Hey, its a great idea! Its hard to argue with that! PockeTerm rocks!
Regarding the 512 byte sectors; you all probably know this already but CP/M only uses 128 byte sectors. Its up to the CBIOS and deblocking routines to convert physical sector format to CP/M format. On the N8VEM IDE CBIOS the physical 512 byte sectors are treated as 4 CP/M sectors packed together. Any read or write to a CP/M sector results in a read or write to the physical sector. That's a very conservative approach but as a result performance takes a hit (no caching and reading/writing 4 adjacent CP/M sectors results in the same physical sector being read/written 4 times). CP/M doesn't appear to support "dirty bits" or any caching AFAIK so implementation can be hazardous. There is no way to "time out" your cache contents.
Thanks and have nice day!
Andrew Lynch
If and when we get around to packing/unpacking I would stick with the conservative approach as you describe. At least initially.
But if we wanted to live dangerously with delayed writes and cached sectors then we can take care of dirty bits and time out the cache content in the emulation.
For CP/M 3 as far as I can tell we can use 512 byte sectors for hard disks and the BIOS takes care of the packing/unpacking.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yep the pockeTerm is/was a starting point for the terminal. It is a great piece of code and I fully acknowledge your work in the code as we discussed. I have a PockeTerm as well and it is a great little board.
Regarding the 512 byte sectors - I plan to do that on the propeller side so CPM has no knowledge of that. I will keep track of which block was last read from the uSD. If I am doing a read and the block is already in memory I will just read from memory - this should improve reads with the 4 sector effective cache. Writes are a little trickier of course. If I have a write and I don't have the block in memory then I have to do a read of the 4 sectors update the written sector in memory and write it out. If it is in memory then update and write it back out. So if I am doing sequential writes every fourth write will incur an extra read before write. If I am doing random read/write then probably every write will incur an extra read. But the normal pattern there is probably read update data then write then I would not incur the extra read as it is already cached. Overall I think there will be a win on the accesses to uSD.
Dave
I do think CPM supports some notion of dirty bits. As I recall from Johnson-Laird book there is a bit that gets set on one of the calls that tells you that this is a directory write and you must perform it immediately. All other writes can be deferred but I plan to do them all anyway. I only have to do the read modify write sequence if I don't already have the disk block in cache.
Dave
I think you are right on the 16 drive limit (I was actually thinking it was 15). I also remember you pay a lot in memory for having a lot of large drives and the performance suffers with large drives as well. On the propIO I was planning on using 4 1MB drives and 4 8MB drives until I can get to CPM3 on N8VEM. So I am not using floppies but will be more aligned with Zicog/triblade. I am planning to not to try to cache writes for the very reasons you point out. But I will reuse the block in memory if it is not dirty to do the write so I don't have to do read modify write on every write to disk. The reads should get a good boost from the 4 sector cache.
Regarding disk blocks I will have to dig up the link to the Johnson-Laird book, it is the bible for CPM internals.
Dave
You have a good point about memory eaten up by having more and bigger drives. I think ZiCog should stay with it's 8 floppies and up to 4 times 8MB drives as well. Until we get to CP/M 3 as you say.
Never seen the Johnson-Laird book. Could be helpful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This is a great book.
http://maben.homeip.net:8217/static/S100/books/CPMbooks/
Both PDF files here a worth downloading. I use Johnson-Laird all the time when I need to refresh memory. I have the hardcopy book but found the PDF online from someone elses reference.
Dave
* max 16 drives but stay with 8 Floppies and 4 Hard Drives = 12 Drives, one hard drive being optional RamDisk
* Make K: the RamDisk (Hard drives are so much faster with DMA
* Make L: later make L: a super large Hard drive - 32MB using 4 x 128byte sectors packed into 512 byte SD sectors - let SD take care of this as there is no overhead for us here - the SD is already handling all this anyway and internally the card is using much larger blocks anyway.
* Floppies - Stick to 128 byte sectors and 1MB on the 32MB card files for CPM. It is no problem to read the 128 byte sector from the SD card
* The floppies are slow because of lack of DMA. If they can be reduced to 4 to save CPM space, this could be a good idea to make room for the extra 2 Hard drives (4 total)
Use the same SD card for both ZiCog and N8VEM if possible
Your thoughts???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Sound goods. I don't see any reason we can't use DMA for the floppies and hard drives as well. CPM supports this. You can use 128 bytes in the first page of memory for the DMA buffer. I personally find more than 4 drives hard to keep track of so I like 2 floppies and 2 hard drives but I am not opposed to what you propose. I think the hard drive and floppy can use common code so if we do 512 byte sectors then I think it will be just as simple to do for floppies as well. Ideally the only thing that distinguishes a floppy from a hard drive is the DPB in CPM. We can use a common emulated controller interface in CPM?
I really want to use same SD between ZiCog and N8VEM (I think we are all in agreement with that
Taking your last suggestion first: "Use the same SD card for both ZiCog and N8VEM if possible"
I don't see this as a requirement at all. My reasoning being:
First we want common floppy disk images between PropIO and ZiCog. This way a "floppies" can be swapped between systems easily. I suggest using the format we have now. SIMH style with 128 byte sectors "stretched" into 512 byte blocks. BUT can we go with the resulting 4MB as the image size rather than 32MB as now? Copying from PC to SD is slow.
Second we want common hard disk images. For the same reason as above.
Here we have a number of "standards" we can define simultaneously I think:
1) SIMH default 8MB style. 128 byte sectors stretched to 512, image size 32MB. This is max for CP/M 2. As we have now.
2) 32MB, 512 bytes sectors in 512 bytes SD blocks. 32MB image size. As formatted by SIMH CP/M 3 when we have configured it so.
3) Whatever huge size CP/M 3 actually supports as a maximum. Again as formatted by SIMH CP/M 3.
My point is I don't see the need for the actual SD card to be identical but rather the image files put into it. After all they all sit on FAT so can be copied around at will.
Question: Is this even possible now? I bet N8VEM disk geometries are different from SIMH. So many things can be different: sectors per track, number of sectors, skew factor, number of blocks reserved for directory entries etc etc. CP/M systems were notoriously bad at being able to read each others floppies.
Now to you points:
* 8 floppies and 4 hard disks - Yep, In line with my desire for SIMH compatibility
* Hard drive as RAM disk - Yep, I don't care what letter but I would have chosen L:
* Super large drive. - Yep, lets find out the max CP/M 3 can handle and define it now. Again as formatted by SIMH CP/M 3. For ZiCog v1.0 I'd like to stick with SIMH compatible 8M for all. Let's go nuts after V1.0
*Floppies - Must be 128 byte sectors. I'd like to see them as 4M image file rather than 32. Speeds up reading/writing files to SD from PC.
*Floppies are slow.... I'd rather not change to 4. This requires a BIOS change and breaks SIMH compatibility we then have to maintain our own CBIOS. Again, at least for ZiCog Z1.0 I'd like to avoid that.
Anyway, as I said above, in terms of compatibility between ZiCog and PropIO, actual drive letters and numbers of each kind of drive are not an issue. Only the actual disk image formats in use are.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here is the nice thing. There are no hard drives or floppies per se defined for the propIO board yet so we have the freedom to define them to be absolutely compatible in layout and style. I would like to have packed floppies because the would be smaller and faster. We could define that way if we want, I can live either way. So I am very flexible in how we go and we can have complete compatibility.
Here is the thing that will be controversial: How close do we need or want to maintain full compatibility with the altairz80? Simh had been in the past modified to support the N8VEM. We could do a similar thing to make Simh, N8VEM with propIO and triblade all be compatible. We could ifdef the CBIOS to accomodate, there would be small changes that would be very minor. The only area that may be a little nasty could be the banked memory. I have not investigated what is supported in SIMH compared to NV8EM but it would be nice if we can make them the same - we can't change the N8VEM very easily as it is done in hardware. We need to investigate if this is easy to map to SIMH and triblade. We need to get Andrew involved as well as he is the leader of the N8VEM and I would not like to go in a direction he may not be comfortable with. Also I want to get N8VEM on the same CPM source base that we are using. I will work with Andrew and others to move to this base. My ultimate goal is to end up on CPM 3 and/or MPM.
Also I would like to support booting from the disk image as well - I think you are already there with triblade and SIMH. I like the N8VEM small monitor that loads and then have a boot loader there that you can select which drive you want to boot off. So we can disk images with CPM 2, CPM 3 and MPM on boot tracks and at boot time to monitor you can choose which you want to boot up.
Also I will be using PockeTerm code on Blade 1 to be the terminal - I don't think that causes any problems as I just direct the serial out/in to blade 1 and 115200 and use the PockeTerm code with a couple of changes.
These are my thoughts - nice to nail all this down up front so we can have a plan for convergence that will link these 2 projects closely together. I am looking forward to the fun ahead
Dave
This means: No DMA for floppies. SIMH emulates MITS Altair 1MB floppy drives (which don't have DMA) and so does ZiCog. SIMH has defined an interface for hard drives with DMA, ZiCog uses the same. It's neat because you can change the hard disk geometry in the emulator rather than hacking the BIOS. The BIOS gets the geometry from the emulator.
This hard disks are about 4 times faster as a result of DMA and will be quicker again with 512 byte sectors.
ZiCog is an MITS Altair simulator like SIMH AltairZ80.
Yes we want a common emulated controller interface and ZiCog is based on Altair and SIMH as a standard.
"I really want to use same SD between ZiCog and N8VEM (I think we are all in agreement with that"
Well I don't see that as necessary, only disk image file compatibility. See my last post.
By the way, what is the interface between N8VEM and Prop? I the Prop just appearing as an I/O device? Or is there more to it. I ask because I don't see how it is possible to do the DMA without a full memory bus between the two and the ability for the Prop to be a bus master.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
OK I understand. We are going to have ifdefs to contain the N8VEM then. I was hoping to go to a simpler floppy/hard disk interface as a common standard. The Altair controller uses more I/O ports than I have left to do the disk interface.
I see what you mean with DMA, propIO looks like 4 I/O ports on the Z80, I have no direct access to the z80 memory. I forgot that cluso has access to the memory as well as the SD in the triblade, so I guess DMA is out for N8VEM. I plan to use INDR and OUTDR which I hope are pretty fast to do the I/O for disk.
Dave
I would like some measure of compatibility between the ZiCog and N8VEM disk image formats. N8VEM is already supported in SIMH and is one of the specified computer systems included in the base install (Thanks to Howard Harte, one of the early supporters of the N8VEM project)
Especially with the PropIO coming out, it will have common media before too long. The N8VEM and PropIO will use the uSD which I believe will be FAT formatted and use 8MB disk images. The N8VEM IDE interface already uses 512 byte physical sectors and does the mapping to CP/M sectors so I believe that a similar arrangement for the uSD disk images.
Personally, I recommend using the 8MB images rather than mapping a single 128 byte CP/M sector into a 512 byte physical sector. I don't think there is much performance gain and its definitely not worth the larger disk images. The disk images are handy if they are portable and 32MB images, most of it empty space, just gets more cumbersome.
Thanks and have a nice day!
Andrew Lynch
Add: I think the safe place to deal with caching is inside the Propeller and its interface to the uSD. Why? Because the Propeller has internal timers and at least the N8VEM does not. That's how to safely handle caching. Once the sectors go "stale", say more than 10 seconds old, they get flushed. I would not recommend write caching due to risk of data corruption.
One could use the N8VEM SBC's DS1302 RTC to "time out" sectors though, now that I think about it a little more. However, for the simplest case CBIOS, I would just pass 128 byte CP/M sectors and let the Propeller handle and deblocking/mapping to physical sectors. Basically the PropIO uSD is a block device like the IDE but simpler. More like the ROM/RAM drive interface.
Add: I do not see how a DMA interface to N8VEM SBC would be possible. The ECB is an IO bus as implemented on N8VEM system. In theory you could use /BUSRQ and /BUSAK to take over the Z80 and do DMA that way but it would be a radical redesign of the PropIO. The typical method is to use IO ports in most CP/M CBIOS designs. There are 4 IO ports on the PropIO now. I suggest a traditional block device style support in CBIOS as the most direct and effective route. Going more exotic would be very difficult and probably require a new design. Were the Propeller local to the CPU and SRAM the situation might be different but those are insulated behind the ECB. The N8VEM was designed for simplicity and reliability not high performance. DMA is great but adds a layer of complexity to the design and makes bus considerations much more complicated.
Post Edited (lynchaj) : 8/23/2009 1:15:05 AM GMT
I am very keen on and attached to SIMH AltairZ80 compatibility. For the following reasons:
1) We don't have to write and maintain our own CBIOS version. In fact looks like 3 or 4 differenet BIOSs would have to be created if we conjoured up our own hardware interface definition. There's CP/3, MP/M etc.
It's taken as two years to get that far and it sounds like a lot of work to go down that road.
2) It's done already, it works, ZiCog already runs CP/M 2 and 3.
3) I'd like to see effort going into getting as much of the CP/M world as possible running correctly on ZiCog/TriBlade before running into reinventing the wheels of the BIOS's for what is, after all, just optimization for ZiCog/TriBlade.
3) With the SIMH Altair interface we can run the original Mits Altair Microsoft BASICs
4) Just as reminder of and tribute to the MITs Altair.
I have to say I find it a bit weird to expect SIMH to carry a ZiCog/TriBlade variation when My whole point for two years now was to be SIMH compatible. As I said to Dr_A it seems a bit recursive, SIMH emulates an Altair, ZiCog emulates SIMH, SIMH then has to include an emulation of ZiCog/triBlade which is emulating SIMH...
To me it's an admission of defeat. A failure to match SIMH.
The ideal would be "SIMH, N8VEM with propIO and triblade all be compatible". SIMH and TriBlade already are.
I'm not sure why banked memory is an issue. N8VEM has its own banking hardware.
ZiCog/TriBlade already boots from disk Images. Basically it copies the boot ROM code into the external RAM at FF00 before starting the Z80 emulation. From there the Z80 emulation boots from disk just like an Altair/SIMH.
Soon, like tomorrow, I will have booting from hard drive images working as well.
My plan for electing different disk images to boot is simple. The emulator Spin code need only prompt the user for which OS he requires to boot. Then it fetches the starting SD block of the appropriate disk image to pass to the disk emulation code. Only a few lines of Spin. No Z80 monitor required.
What do you make of my concerns over the different disk geometries and layouts between N8VEM and those of ZiCog/TriBlade/SIMH?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Can we brainstorm this a bit more? You have been deep inside the IDE code. Are you saying that the physical sectors are 512 byte? I got the impression that 128 was the only option but maybe not. I see 80H as the sector size but that is a word, not a byte, so presumably you can go for 02H high byte and 00H low byte for 512? If so, would you be able to post the dpb for your IDE and maybe we could drop it into the spin code and see if it works.
Or is it more complex than that? Reads are simple, but say I have 128 bytes to write and the sd card can only handle it in 512 chunks. Do you then need to read 512 into a buffer, overwrite 128 of them with the new data and write out all 512? I think that was the reason cluso went for drive images that are 32mb.
Post Edited (Dr_Acula) : 8/23/2009 1:15:18 AM GMT
That is the level of interchangabilty I am aiming for in ZiCog/TriBlade.
Yes, caching should be handled in the Prop as Andre describes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Part of the confusion here is that N8VEM SBC has physical memory mapping by the RAM and ROM Memory Page Configuration Latches (MPCLs). The N8VEM SBC supports CP/M 2.2 at the moment. I would like it to upgrade to CP/M 3.0 eventually but that is not a trivial undertaking. In CP/M 2.2, there are only character and block devices. All block devices are fundamentally 128 byte sector devices from the CP/M perspective. Any deviations from that are handled in the CBIOS. Basically, all block devices are IBM 3740 8" floppy disks.
I would very much like to support a common format between the N8VEM drive images and the ZiCog/Triblade approach. This may require some sort of translation layer though. Either a conversion utility or CBIOS or PropIO Propeller code to support to recognize the different image formats and handle the differences. If the interface of the PropIO to the N8VEM SBC just passes 128 byte CP/M sectors, then you can place whatever disk image format you like as long as the Propeller code can address the differences. I would prefer an efficient use of space even if it is cheap because the disk images are really portable files and meant for interchange among builders.
In the N8VEM SBC perspective, there is no difference between ROM images and disk images -- they are the same thing. The main 1MB ROM is mounted as the F: drive on the SBC and also in SIMH. In SIMH F: is read/write so you can update it. In the N8VEM SBC it is RO (an EPROM). What is cool is that you can take the ROMIMAGE.BIN file straight out of the SIMH, burn a 27C080, stuff it into an SBC and have a highly reliable RO file system. There are DPBs for all the ROM and devices in the CBIOS.
In theory, that is possible. The CBIOS would have to support that disk images DPB though. The 1MB ROM is directly supported in SIMH. You could copy the contents of another disk image to the F: drive, pull that ROMIMAGE.BIN out and burn an EPROM and drop it in. Likewise put it on the hard drive (the 1MB partition).
The N8VEM SBC does not support a random disk image with random DPB dropped into the drives though. That's a great idea but would require some infrastructure to handle something like that.
Thanks and have a nice day!
Andrew Lynch
Concur. Don't leave home without it. I strongly recommend this book and the CP/M modification guide to anyone considering building their own CBIOS.
Thanks and have a nice day!
Andrew Lynch
Add: If there are any N8VEM specifics you'd like to know please let me know. I've read the thread and tried to address all the points. Compatibility between these highly similar projects would be a good thing.
The N8VEM home brew computing project is not a "top down management style" project. It is more like brownian motion. I don't force anyone to do anything. What makes things happen is motivated and skilled developers like James, Dave, Dan, Howard, Rich, Bill, Juha, Rolf, et al. They make it happen. They pursue *their* interests in home brew computing. The N8VEM project is basically a container or library of parts the builders use themselves to pursue their interests. This is why I think N8VEM and Propeller are such kindred spirits. You can feel the frenetic builder energy on the Propeller forums and its the same driven energy you see on the N8VEM mailing list. People who want to make things make it happen. At best, I am a facilitator and certainly not a dictator. Actually, most of the time I am more like a cheer leader than anything. I do encourage some highly motivated builders into certain "highly desired" areas such as floppy drive support and the Propeller project. However, even the Propeller project has started life several times in different incarnations before becoming the just incredibly awesome PropIO project. James can vouch for it, the Propeller and N8VEM projects are highly intertwined for about a year now. This is only meant to be an explanation of where I'm coming from.
Post Edited (lynchaj) : 8/23/2009 1:52:33 AM GMT
I am happy to defer packing of sectors till V2. What we should do though is come up with a common set of disk geometries. Since I will be starting the uSD integration into propIO next week I would like to keep as much in common as possible. I really would like to keep the CBIOS as much as common as possible. I think I can probably move the conin and conout to the same place as the Altair if it doesn't conflict with the I/O on the N8VEM, it is a simple change for me. The disk ports will definitely be different which will cause ifdefs in the CBIOS. I need to look at how SIMH does bank memory (does SIMH do banked memory as that would have been beyond an Altair ?). If possible we could make this common or this will be another set of ifdefs. Either way if we want the ultimate commanality, we will introduce a set of ifdefs into the CBIOS. I don't think that is that bad as how often is the CBIOS changing?
In terms of booting I still like the monitor - kind of still in the spirit of a real z80 system, but we can make it work both ways.
Dave
Disk drive files on microSD (or SD)
I am using a low level driver to access the files which are effectively "drives". Their format is unimportant to CPM because this is all handled within a line in spin for each of:
Now, my files are exact SIMH files converted to an SD file by VB as follows:
Heater's emulation for the Prop Development Board (is this the right pcb?) without external SRAM uses the above files except that:
CPM Floppy and Hard Drive Access
Now let me clear up a few misconceptions for the above access by CPM, spin, etc:
So, unless·standard CPM can read/write·512 byte sectors there is no benefit in going this route.
The reason I have suggested we change to 4 x 128 byte sectors is as has been raised,·it is easier to download·the smaller disk files for SD cards. So I suggest we change now ready for version 1.0. If all are in agreement, I will modify my VB program and re-generate and re-post the files. I can probably do it·in the next 5-6 hours, then I will be·pretty much off-air for 48 hours.
CPM2.2, CPM3, MPM
Likewise, unless there is any benefit (saves CPM space, like the extra 2 hard disks·require 700+ bytes) then there is no point to reduce 8 floppies to less. 4 hard drives should be great - 2 x standard 8MB + 1 x RamDisk + 1 x Large drive (hdp to specify) - these are all defined in spin anyway. I currently use a #define to switch the A: drive between CPM2 and CPM3. This question could be asked on bootup, if required. I envisage CPM3 banked and MPM will all use this technique.
Banked Memory
On the TriBlade, we have a block of contiguous SRAM (either 512KB or 1MB). The balance of what CPM requires can be used as a RamDisk. Remember, we only have RAM, not EPROM. There is no programming EPROMs. The RamBlade will only have 512KB of SRAM.
The code that I have done (I found the requirements somewhere, but I don't recall) uses $0000-$DFFF as the bank section and $C000-$FFFF as the fixed section. Software switches in/out 5 x 48KB banks from $0000-$DFFF. In reality, the driver just adds the offset if the Z80 adress is <$C000 on each memory access. Therefore, 256KB of memory is required.
I·hope this makes sense. What are your thoughts???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 8/23/2009 12:21:31 PM GMT
Post Edited (Dr_Acula) : 8/23/2009 7:08:30 AM GMT
After a nights sleep I'm changing my mind and warming up to packing of 4 times 128 bytes into 512 bytes SD sectors. Why:
1) All round speed gain for floppies and HDs (factor of 4?)
2) Quicker copying of images to/from SD card.
3) It cannot be so hard. Only a few lines of Spin. Leave out any delayed writes initially.
4) Looks like we want the image layout defined NOW.
5) Even if we have gigs of space it just seems aesthetically crappy to waste 32MB of SD for 8MB of data.
Yoda's points:
Yes banked memory was beyond the Altair. I guess SIMH added that enhancement for CPM/3.
I don't understand how this impacts PropIO - ZiCogTriBlade compatibility. Isn't that confined to the N8VEM's Z80 - memory interface? Or am I missing a point here?
Re: a monitor program. ZiCog does not have one but if a Z80 monitor is needed ZiCog could load it from an SD file into the CP/Ms RAM and then start the emulation. Easy. Perhaps we should think about doing that. Then it would be nice to have similar monitor programs in N8VEM and ZiCog. I like the idea, as you say "in the spirit of of a real Z80 system".
Cluso's points:
There is some confusion re-sector size in CP/M.
CP/M (at the BDOS level as far as I understand) only understands 128 byte "logical" sectors. However the BIOS can be written to work with different physical sector sizes. The BIOS then takes care of packing/unpacking the logical sectors into physical sectors. For SIMH and ZiCog/TriBlade and CP/M 2 the BIOS only supports 128 byte sectors all round. With CP/M 3 it has a different BIOS that will block/deblock 512 byte physical sectors.
Anyway I now feel we should shoot for packing 4 * 128 byte sectors into 512 byte SD blocks, as I said above. If I understand correctly you are into that as well. We will do the blocking/unblocking in Spin. Then sometime we can configure CP/M 3 to use 512 byte sectors and it will just use the same disk image if the blocking/deblocking is disabled in Spin.
Again, I don't thing the assignment of drive letters or quantities of floppy hard disks is an issue for PropIO - ZiCog compatibility. That should be configurable at build time (of the Spin emulation) or at run time.
As long as our actual images are interchangeable between the two systems.
That banked memory layout spec we are using I derived from the SIMH implementation of course. Turns out is very simple for us to implement in the PASM Z80 emulation. This is important because memory banking impacts the execution speed of every memory access by the emulator. If the banking model were any more complicated the emulation would get slowed.
In summary I suggest:
1) Let's do the sector packing/unpacking. In Spin. We can then present 512 byte sectors to N8VEM.
2) Let's define the current SIMH 1MB floppy and 8MB hard drives as a "standard". With the difference that for floppies the 137 byte Altair sectors are trimmed to 128 before packing into 512 bytes SD blocks. A simple script or BASIC prog is all that is required to do that trimming.
3) Let's figure out the biggest disk CP/M 3 supports for Cluso's "huge" disk standard.
4) Hopefully we can drop an N8VEM console port emulation into some free I/O addresses.
BINGO we have interchanges able disk images, more speed and smaller downloads.
What do you reckon?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.