Great. Have you got it soldered up yet? Sorry about the old-school D9 serial plug, but I figured that down the track you could build null modem cables that swap Tx and Rx and then use the serial ports as comms between these boards.
CP/M would have no truck with that new fangled USB stuff. And whilst we are discussing this, get that 9 pin off the board and use the proper 25 way !!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Dr_A, it came assembled remember, I know you may have slept once or twice since sending it [noparse]:D[/noparse] lol
Toby, yes, don't worry, I know they weren't USB'd back then lol, I remember having an Amstrad PCW 8512 back in around 1985-6 for work, we had that connected to a Spectrum and Amstrad CPC464 over serial to program [noparse]:)[/noparse]
Oh yes, that's right. I sent off so many boards in those few days. So - are you ready to join in with debugging the zicog and getting all the Z80 instructions working?
Attached - up to the minute archive - working on just the zicog at the moment.
I just read back a load of posts, a noticed a couple of questions to me, sorry. The caps on the power side of my version are, 100u after input diode and input of the 5V reg, 220u between the 5V and 3.3V regs, 10u out of the 3.3V reg but this then goes onto the main board which has 220u etc, etc on it.
I tried to delay the start, to give it a chance to settle, but no amount changed anything. I have tried a 100u setup on the reset pin, which held everything up for a few secs, nothing changed. I will try another PSU (9V SMPSU).
The reset button works everytime, if you tap out "morse code" on it the software will still strike up perfectly, every time. This isn't a real problem as I will just have to poke the reset button.
Even more nostalga !!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Re "The caps on the power side of my version are, 100u after input diode and input of the 5V reg, 220u between the 5V and 3.3V regs, 10u out of the 3.3V reg but this then goes onto the main board which has 220u etc, etc on it."
So I gather you are running the input volts through the 5V then into the 3V reg?
The original design uses switchers and there is an input of 7V to 20V going into both switchers, rather than the volts going into one then out of that one into the other. The nice thing about switchers is very little power is wasted as heat so there is no need to 'pre regulate' with a 5V reg.
This could be relevant because with switchers both supplies will come up to regulated volts at about the same time. With 5V=>3V the 3V will come up to regulation first and then the 5V one. So there could be some current going in and out of some of the 5V supplied chips which might be upsetting things along the way.
If the reset button works then use that for the moment.
On another note, see also the zicog thread for updates on getting all the Z80 opcodes working.
Yes I am using X Volts to 5 Volts to 3.3 Volts with SM regs which are as usual recycled junk (Sony video printer). The only new bits on it are the PCB, Prop, Memory, solder and the 74hcXXX, everything else is second hand.
The next thing to try would be to delay thr reset line lifting, for a second or so, I tried a 100uF cap and some diodes but I don't know if the beasty didn't like such a slowwwwww rising edge.
I have put a link on Zicog thread, for a Z80 Manual.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Yes, chained power supplies may be an issue. Delayed resets could be possible - I'm not sure exactly what is needed on that reset line - it might be a H,L,H transition, not just a rising pulse. This might end up being a schmitt trigger or a 555 circuit.
I'm eagerly awaiting heater fixing the exz80 exerciser, but meanwhile, I have had a crazy idea. How cool would it be to be able to access the SD card files directly from CP/M?
I think it is possible. There are 6 simple commands the sd card driver uses:
Start reading file names
Read next file name
Open a file
Read n bytes
Write n bytes
Close a file
I just wrote some quick code in spin to capture an OUT to a nominal port (70H) with n=0 to 255 passed to that port.
Then a tiny .MAC program in CP/M and I can capture that and use a 'case' command to go to the right pub.
Reading file names should be easy, so a DIR of the sd card should be possible.
But reading and writing files may be more difficult. The problem is you can't read the file in pieces as the sd card driver can only have one file open at a time, and it already has the disk image file open, so it can't open another one.
How could this be solved?
1) is there an sd card driver than can have two files open at once (probably not).
2) buffer the entire file in CP/M memory. The machine code might be only 1k and CP/M sits right at the top of memory, so files up to 55k or so could be copied in this way.
3) use the rest of the sram chip, up to 448k as the buffer. But then you can't use it for anything else.
I'm moving towards 2, as the only file in CP/M I can find that is huge is wsprint.ovl (147k). The rest are mostly <30k.
make a few CPM commands that can "transfer" the files into the CP/M images.
I suggest
fatdir
fatget
fatput
Just access the raw blocks... and prot fsrw!
Dr_Acula said...
Yes, chained power supplies may be an issue. Delayed resets could be possible - I'm not sure exactly what is needed on that reset line - it might be a H,L,H transition, not just a rising pulse. This might end up being a schmitt trigger or a 555 circuit.
I'm eagerly awaiting heater fixing the exz80 exerciser, but meanwhile, I have had a crazy idea. How cool would it be to be able to access the SD card files directly from CP/M?
I think it is possible. There are 6 simple commands the sd card driver uses:
Start reading file names
Read next file name
Open a file
Read n bytes
Write n bytes
Close a file
I just wrote some quick code in spin to capture an OUT to a nominal port (70H) with n=0 to 255 passed to that port.
Then a tiny .MAC program in CP/M and I can capture that and use a 'case' command to go to the right pub.
Reading file names should be easy, so a DIR of the sd card should be possible.
But reading and writing files may be more difficult. The problem is you can't read the file in pieces as the sd card driver can only have one file open at a time, and it already has the disk image file open, so it can't open another one.
How could this be solved?
1) is there an sd card driver than can have two files open at once (probably not).
2) buffer the entire file in CP/M memory. The machine code might be only 1k and CP/M sits right at the top of memory, so files up to 55k or so could be copied in this way.
3) use the rest of the sram chip, up to 448k as the buffer. But then you can't use it for anything else.
I'm moving towards 2, as the only file in CP/M I can find that is huge is wsprint.ovl (147k). The rest are mostly <30k.
Thoughts would be most appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Yes, initially I was going to do it in raw blocks, especially as I already have the CP/M code written in assembly to talk to a uDrive from 4Dsystems.
The problem is having two files open at once. I don't think it can be done in pieces. On the read side, you can have a counter I suppose, and on the first block read in bytes 0-127, and on the second read, close the file, reopen it, read bytes 0-127 and discard them and then read bytes 128 to 255 etc. The problem is the write side. Unless - is there an append command? You could then open a file and close it for each record, and append 128 bytes each time on the end of the file.
Ah - good news I found this in fsrw "Open modes are 'r' (read), 'a' (append),
' 'w' (write), and 'd' (delete)."
So it would involve many opens and closes on each file - as you would have to open the file, get a record, close it, open the disk image file, write the record, close it etc. 2 opens per record.
Moving the entire file into memory may be a lot quicker... I'll need to think about this more.
Then again, a PIP from drive A to drive B involves lots of opening and closing. Actually, PIP might even be able to do this with no code changes as PIP can send data to other places. PIP takes a bit of space itself (7.25k) but you could PIP to a pseudo port which is some spin code that then dumps the data to memory 8k and up OR to high memory above 64k. Then when it finishes, write that out to the sd card.
Dr_A, Sorry for the delays in getting EX. We are having some seriously not working field trials of the first pilot installation of the product we've been working on all year! Result is I've been hanging on the phone fielding calls from our installation engineers and generally fire fighting this week. Plenty of breaks to chat here but generally I'm away from my Prop stuff. Looks like the situation may settle down today though.
I don't understand where you want to go with "access the SD card files directly from CP/M".
If you want to move files from CP/M to FAT we should be implementing the same R and W commands as used by SIMH. They just push and pull files between CP/M and the simulation through a special I/O port in Z80 space. See the source codes R.SPL and W.SPL.
There should be no problem with opening files. When the emulation is running there should be no files open by the FAT level driver. I'm not sure now but if it did OPEN the disk image file whilst getting the start block number it should close it again before running the emu. After all the CP/M emulation is using direct block read/write to the SD CARD not using FAT.
Or do you mean there is a problem with the low level SD block driver being shared between FAT and emu? That should be easier to fix.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@heater, I feel your pain. I suppose they want it all fixed before xmas? In medicine we call it "magic wand week" - little Johnny and little Susie need to be fixed right now as we are going away on holidays...
Any time you can spend on the ex will be most appreciated.
Yes, the aim is to impelement R and W. I didn't know there was source code around - thanks for that. Though I still think it is going to be more complex than just running R or W. I just can't see how to do this in blocks.
But on looking through my uDrive code I have the code for moving the entire file into up to 50k of memory so at least the Z80 side is already coded. Just need to then use spin to get the file from memory and move to an sd file. And I'd like to be able to run SDDIR.COM and it shows the files on the sd card, including the disk images and any other loose files lying around. I'm thinking this could be a handy way to transfer files quicker than xmodem transfers (which do work fine btw).
Drac: I am a little confused at how you are wanting to achiece this. There are spin routines which will handle all the FAT16 FileI/O stuff. ZiCog does not have a file open. All ZiCog access is done as raw sector address accesses for CPM.
P.S. Just driven down from the Gold Coast to Gosford (Sydney). So maybe some time for my hw over the w/e
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ah Cluso, so if CP/M asks for a record in the middle of a file, does spin open the file, read the record then close the file? Or, indeed, is it even more cunning with the 128vs512 byte thing where it reads off 512 bytes and buffers the other 3 records. Either way, if the .dsk image is closed that makes things much easier to code.
I don't think CP/M ever has to ask for a record in the middle of a file when reading a file from FAT it should not know or care about FAT.
Consider this:
1) Assume CP/M had an extra serial port readable and writable at some new I/O address.
2) The other end of this serial connection does not go anywhere except that bytes are written/read from it by the Spin emulation code.
3) When CP/M wants to read a file it sends out the file name down this port.
4) Then it reads form the port to get all the bytes of the file writing them to a CP/M file as it goes.
5) Meanwhile on the Spin end of that I/O port the Spin code accepted the file name, opened the file, then reads all the bytes of the file sending into the port as it goes then closed the file.
Similarly for CP/M writing a file.
Of course there would have to be some kind extra protocol with this to initiate the transfer, send file names, possibly know how long the file names are, knowing how many bytes of file to expect, terminating the transfer.
This is how SIMH implements R and W through the special SIMH I/O port. If we want to do this we should implement in Spin what SIMH does with that SIMH port number, then we could use the existing R.COm and W.COM commands unchanged.
Alternatively we do something similar but with a different protocol, which might be easier in Spin, and our own custom R and W commands.
Now it occurs to me that we should do something a bit different. Transfer blocks at at time rather than bytes. Something like this:
1) Our new CP/M "R" command writes out a file name to the I/O port which is read by Spin on the other end.
2) It also sends out the address in Z80 space of a 128 or 512 byte block buffer in which to receive the incoming file.
3) The Spin code reads the first block of the file from FAT, puts it in the block buffer in ext RAM and the writes the size of the buffer back to that I/O port.
4) The "R" program, receives the size from the port and writes the data from block buffer to the CP/M file.
A the the end of the file if there are not enough bytes to fill a block Spin pads the block with zeros.
When all the file is done Spin returns zero up the I/O port as the size. and the "R" program knows to stop.
Basically we "DMA" the file a block at a time in and out of CP/M.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think the block stuff may be a little more than CP/M can handle but is an interesting idea. DMA would be tricky as CPM in program space probably would not react to this well. You would have to handle checking the completion and things like that yourself. I think probably the serial way would be the most straight forward and simple to implement. It will cause a little thrashing in the spin side as you can only have one file open at a time so you would be opening and closing the cpm disk and the file you are trying to transfer quite a bit.
@James
I don't see the real benefit of this. As you could easily write an extract on the pc side and copy in an out of the cpm disk image - there are a lot of tools like that already. If you have a mixed filesystem that means you had it in a PC or Linux system to create that, so it is just as easy at that point to move the file(s) from there.
Yoda: No, I said elsewhere as did heater, we do not have files open for cpm access to the hard drive files. We just access them in the low level driver directly as sectors on the SD card. Heater buffers (caches) the 512 bytes and feeds the required 128 bytes to cpm.
I am still unsure of what the objective is in cpm writing a FAT16 file. Is it to transfer a usable file (say a text file or a binary) from cpm disk to a file under the FAT16 structure ? How is the FAT16 file going to be used?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso, yes, that is correct. Sorry about causing all this confusion. It is my fault as I've not been totally explicit about the code - when I say "file open" I also include opening a disk image file. The problem comes down to this bit of code:
' **
' r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD
' CheckError(r)
' this method relies on the SD file using contiguous sectors !!! Packed 4 x 128 bytes per 512 byte sectors
err := \sd.readSDCard(sd_block_number, @disk_buff, 512) 'read the block! (complete 512 bytes)
' **
' r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running)
' CheckError(r)
Now, on the triblade the sd pins are used for several things, so you have to shut down the sd card completely after getting a 512 byte record.
On the dracblade, the sd pins are only used for the sd card, so I leave the sd card running. You can see this in the commented out code. This has been done as it speeds up the emulation (which tends to offset the slower code talking to the ram).
So, if I only ever do an sd.init right at bootup, and I'm reading blocks with sdreadsdcard() and writing blocks, can I also use fsrw to be talking to a FAT16 file at the same time? More specifically, is sd.readsdcard leaving the disk image file 'open' in some way?
As for the reason for this, consider someone wants to send you a CP/M program for your board. Well, you can xmodem it over. You can get a .dsk image off the sd card, put it into a directory with a working simh emulation, rename the disk image, do a read, rename the .dsk file again, copy it back to the sd card and put it back into the Zicog board. Or ... you could just put it onto the sd card and use a program SDR.COM to read it into CP/M. I'm thinking of people who don't have a simh emulation set up and/or don't have an IDE like mine that can do batch xmodem file transfers.
Or... maybe there is no need for this?
Or.... (I guess the most honest answer), I was looking to keep busy while waiting for heater's new exz80 program!
Addit- did some testing. It seems to work ok. I've got the bare bones (top down programming) skeleton to handle all the I/O commands in Spin and I've got a program that sends out bytes to the new port and it created a new TEST.TXT on the sd card and CP/M still seemed to run fine afterwards. 90% of the coding is on the CP/M side but that already exists. The spin side seems ultra simple thanks to fsrw.
@Cluso - yes I understand - my bad, we are just reading and writing blocks - not using the FAT system
@James
If you use xmodem then you are not using the FAT files. For your other example, it means you have the SD card plugged into your PC, so you could use the cpm* tools and do a cpmls on your dsk image to get a directory listing of you dsk file and use cpmcp to copy the new CPM files into the dsk image or from the dsk image to you PC so you don't have to rewrite anything since it is all in place.
I am not sure if using the sd.readSDcard upsets an open file. It does not leave a file open as such - we are directly reading/writing to a sector on the SD card based from 0 - there is no FAT16 file reference being done once we obtain the starting sectors of each disk file.
This you will have to check for yourself. There may also be other ways to fudge this.
It may be simpler to do the whole transfer in spin without ZiCog. The spin driver could be made aware of the CPM file structure and copy files to/from CPM to FAT16.
Timing: Are you using the latest fsrw25 (mb_rawb_spi25_rr003.spin) driver? This should not take much time to release the shared SD pins anymore. This was only an issue with the old driver.
I am thinking it would be nice to be able to time some things in CPM. I think I mentioned this before. What we need is·an Input routine that reads the 'CNT' value. Even more simply, if cpm wrote to an output port, it could display the 'cnt' value to the terminal/serial. Any thoughts???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Hei, guys what's the problem. Consider Linux, it can have many files open at the same time. Whilst one program thinks it has a file open as FAT or ext3 or whatever another can be accessing raw disk blocks with "dd".
All we are asking is that the FAT guy and the emulation can "borrow" SD card access from each other without tripping each other up.
As to why we want to do this. Easy, drop a file into FAT from the PC, put the SD into TriBlade, read the file into CP/M. No messing with odd tools etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@heater - guess it is just as easy to say cmpcp <file> f:\a.dsk as copy <file> f:\ (where is f is the drive the sd is mounted at) and then it is already in the cpm disk image. Seems simpler and the tool already exists for windows and linux and source comes with it. The latter way requires 2 steps - you then have to insert into CPM and copy it again into the cpm filesystem plus the code for that doesn't quite exist yet.
@heater: Well this is probably a problem with not using fully packed sectors. We can probably do some hacking to get it to read and write correctly. I think it is the 128 bytes in a 512 byte sector that is causing the problem. I think the cpmtools assume that the data is contiguous within the file.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
CP/M would have no truck with that new fangled USB stuff. And whilst we are discussing this, get that 9 pin off the board and use the proper 25 way !!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Toby, yes, don't worry, I know they weren't USB'd back then lol, I remember having an Amstrad PCW 8512 back in around 1985-6 for work, we had that connected to a Spectrum and Amstrad CPC464 over serial to program [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Attached - up to the minute archive - working on just the zicog at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/16/2009 10:33:44 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I tried to delay the start, to give it a chance to settle, but no amount changed anything. I have tried a 100u setup on the reset pin, which held everything up for a few secs, nothing changed. I will try another PSU (9V SMPSU).
The reset button works everytime, if you tap out "morse code" on it the software will still strike up perfectly, every time. This isn't a real problem as I will just have to poke the reset button.
Even more nostalga !!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
So I gather you are running the input volts through the 5V then into the 3V reg?
The original design uses switchers and there is an input of 7V to 20V going into both switchers, rather than the volts going into one then out of that one into the other. The nice thing about switchers is very little power is wasted as heat so there is no need to 'pre regulate' with a 5V reg.
This could be relevant because with switchers both supplies will come up to regulated volts at about the same time. With 5V=>3V the 3V will come up to regulation first and then the 5V one. So there could be some current going in and out of some of the 5V supplied chips which might be upsetting things along the way.
If the reset button works then use that for the moment.
On another note, see also the zicog thread for updates on getting all the Z80 opcodes working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Yes I am using X Volts to 5 Volts to 3.3 Volts with SM regs which are as usual recycled junk (Sony video printer). The only new bits on it are the PCB, Prop, Memory, solder and the 74hcXXX, everything else is second hand.
The next thing to try would be to delay thr reset line lifting, for a second or so, I tried a 100uF cap and some diodes but I don't know if the beasty didn't like such a slowwwwww rising edge.
I have put a link on Zicog thread, for a Z80 Manual.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
I'm eagerly awaiting heater fixing the exz80 exerciser, but meanwhile, I have had a crazy idea. How cool would it be to be able to access the SD card files directly from CP/M?
I think it is possible. There are 6 simple commands the sd card driver uses:
Start reading file names
Read next file name
Open a file
Read n bytes
Write n bytes
Close a file
I just wrote some quick code in spin to capture an OUT to a nominal port (70H) with n=0 to 255 passed to that port.
Then a tiny .MAC program in CP/M and I can capture that and use a 'case' command to go to the right pub.
Reading file names should be easy, so a DIR of the sd card should be possible.
But reading and writing files may be more difficult. The problem is you can't read the file in pieces as the sd card driver can only have one file open at a time, and it already has the disk image file open, so it can't open another one.
How could this be solved?
1) is there an sd card driver than can have two files open at once (probably not).
2) buffer the entire file in CP/M memory. The machine code might be only 1k and CP/M sits right at the top of memory, so files up to 55k or so could be copied in this way.
3) use the rest of the sram chip, up to 448k as the buffer. But then you can't use it for anything else.
I'm moving towards 2, as the only file in CP/M I can find that is huge is wsprint.ovl (147k). The rest are mostly <30k.
Thoughts would be most appreciated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I suggest
fatdir
fatget
fatput
Just access the raw blocks... and prot fsrw!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
The problem is having two files open at once. I don't think it can be done in pieces. On the read side, you can have a counter I suppose, and on the first block read in bytes 0-127, and on the second read, close the file, reopen it, read bytes 0-127 and discard them and then read bytes 128 to 255 etc. The problem is the write side. Unless - is there an append command? You could then open a file and close it for each record, and append 128 bytes each time on the end of the file.
Ah - good news I found this in fsrw "Open modes are 'r' (read), 'a' (append),
' 'w' (write), and 'd' (delete)."
So it would involve many opens and closes on each file - as you would have to open the file, get a record, close it, open the disk image file, write the record, close it etc. 2 opens per record.
Moving the entire file into memory may be a lot quicker... I'll need to think about this more.
Then again, a PIP from drive A to drive B involves lots of opening and closing. Actually, PIP might even be able to do this with no code changes as PIP can send data to other places. PIP takes a bit of space itself (7.25k) but you could PIP to a pseudo port which is some spin code that then dumps the data to memory 8k and up OR to high memory above 64k. Then when it finishes, write that out to the sd card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I don't understand where you want to go with "access the SD card files directly from CP/M".
If you want to move files from CP/M to FAT we should be implementing the same R and W commands as used by SIMH. They just push and pull files between CP/M and the simulation through a special I/O port in Z80 space. See the source codes R.SPL and W.SPL.
There should be no problem with opening files. When the emulation is running there should be no files open by the FAT level driver. I'm not sure now but if it did OPEN the disk image file whilst getting the start block number it should close it again before running the emu. After all the CP/M emulation is using direct block read/write to the SD CARD not using FAT.
Or do you mean there is a problem with the low level SD block driver being shared between FAT and emu? That should be easier to fix.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Any time you can spend on the ex will be most appreciated.
Yes, the aim is to impelement R and W. I didn't know there was source code around - thanks for that. Though I still think it is going to be more complex than just running R or W. I just can't see how to do this in blocks.
But on looking through my uDrive code I have the code for moving the entire file into up to 50k of memory so at least the Z80 side is already coded. Just need to then use spin to get the file from memory and move to an sd file. And I'd like to be able to run SDDIR.COM and it shows the files on the sd card, including the disk images and any other loose files lying around. I'm thinking this could be a handy way to transfer files quicker than xmodem transfers (which do work fine btw).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
P.S. Just driven down from the Gold Coast to Gosford (Sydney). So maybe some time for my hw over the w/e
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Consider this:
1) Assume CP/M had an extra serial port readable and writable at some new I/O address.
2) The other end of this serial connection does not go anywhere except that bytes are written/read from it by the Spin emulation code.
3) When CP/M wants to read a file it sends out the file name down this port.
4) Then it reads form the port to get all the bytes of the file writing them to a CP/M file as it goes.
5) Meanwhile on the Spin end of that I/O port the Spin code accepted the file name, opened the file, then reads all the bytes of the file sending into the port as it goes then closed the file.
Similarly for CP/M writing a file.
Of course there would have to be some kind extra protocol with this to initiate the transfer, send file names, possibly know how long the file names are, knowing how many bytes of file to expect, terminating the transfer.
This is how SIMH implements R and W through the special SIMH I/O port. If we want to do this we should implement in Spin what SIMH does with that SIMH port number, then we could use the existing R.COm and W.COM commands unchanged.
Alternatively we do something similar but with a different protocol, which might be easier in Spin, and our own custom R and W commands.
Now it occurs to me that we should do something a bit different. Transfer blocks at at time rather than bytes. Something like this:
1) Our new CP/M "R" command writes out a file name to the I/O port which is read by Spin on the other end.
2) It also sends out the address in Z80 space of a 128 or 512 byte block buffer in which to receive the incoming file.
3) The Spin code reads the first block of the file from FAT, puts it in the block buffer in ext RAM and the writes the size of the buffer back to that I/O port.
4) The "R" program, receives the size from the port and writes the data from block buffer to the CP/M file.
A the the end of the file if there are not enough bytes to fill a block Spin pads the block with zeros.
When all the file is done Spin returns zero up the I/O port as the size. and the "R" program knows to stop.
Basically we "DMA" the file a block at a time in and out of CP/M.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I think the block stuff may be a little more than CP/M can handle but is an interesting idea. DMA would be tricky as CPM in program space probably would not react to this well. You would have to handle checking the completion and things like that yourself. I think probably the serial way would be the most straight forward and simple to implement. It will cause a little thrashing in the spin side as you can only have one file open at a time so you would be opening and closing the cpm disk and the file you are trying to transfer quite a bit.
@James
I don't see the real benefit of this. As you could easily write an extract on the pc side and copy in an out of the cpm disk image - there are a lot of tools like that already. If you have a mixed filesystem that means you had it in a PC or Linux system to create that, so it is just as easy at that point to move the file(s) from there.
I am still unsure of what the objective is in cpm writing a FAT16 file. Is it to transfer a usable file (say a text file or a binary) from cpm disk to a file under the FAT16 structure ? How is the FAT16 file going to be used?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (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
' ** ' r := sd.initSDcard(spiDO,spiClk,spiDI,spiCS) 'init the SD ' CheckError(r) ' this method relies on the SD file using contiguous sectors !!! Packed 4 x 128 bytes per 512 byte sectors err := \sd.readSDCard(sd_block_number, @disk_buff, 512) 'read the block! (complete 512 bytes) ' ** ' r := sd.stopSDcard 'stop the SD (free up pins, but keep cog running) ' CheckError(r)Now, on the triblade the sd pins are used for several things, so you have to shut down the sd card completely after getting a 512 byte record.
On the dracblade, the sd pins are only used for the sd card, so I leave the sd card running. You can see this in the commented out code. This has been done as it speeds up the emulation (which tends to offset the slower code talking to the ram).
So, if I only ever do an sd.init right at bootup, and I'm reading blocks with sdreadsdcard() and writing blocks, can I also use fsrw to be talking to a FAT16 file at the same time? More specifically, is sd.readsdcard leaving the disk image file 'open' in some way?
As for the reason for this, consider someone wants to send you a CP/M program for your board. Well, you can xmodem it over. You can get a .dsk image off the sd card, put it into a directory with a working simh emulation, rename the disk image, do a read, rename the .dsk file again, copy it back to the sd card and put it back into the Zicog board. Or ... you could just put it onto the sd card and use a program SDR.COM to read it into CP/M. I'm thinking of people who don't have a simh emulation set up and/or don't have an IDE like mine that can do batch xmodem file transfers.
Or... maybe there is no need for this?
Or.... (I guess the most honest answer), I was looking to keep busy while waiting for heater's new exz80 program!
Addit- did some testing. It seems to work ok. I've got the bare bones (top down programming) skeleton to handle all the I/O commands in Spin and I've got a program that sends out bytes to the new port and it created a new TEST.TXT on the sd card and CP/M still seemed to run fine afterwards. 90% of the coding is on the CP/M side but that already exists. The spin side seems ultra simple thanks to fsrw.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/19/2009 3:52:43 AM GMT
@James
If you use xmodem then you are not using the FAT files. For your other example, it means you have the SD card plugged into your PC, so you could use the cpm* tools and do a cpmls on your dsk image to get a directory listing of you dsk file and use cpmcp to copy the new CPM files into the dsk image or from the dsk image to you PC so you don't have to rewrite anything since it is all in place.
I am not sure if using the sd.readSDcard upsets an open file. It does not leave a file open as such - we are directly reading/writing to a sector on the SD card based from 0 - there is no FAT16 file reference being done once we obtain the starting sectors of each disk file.
This you will have to check for yourself. There may also be other ways to fudge this.
It may be simpler to do the whole transfer in spin without ZiCog. The spin driver could be made aware of the CPM file structure and copy files to/from CPM to FAT16.
Timing: Are you using the latest fsrw25 (mb_rawb_spi25_rr003.spin) driver? This should not take much time to release the shared SD pins anymore. This was only an issue with the old driver.
I am thinking it would be nice to be able to time some things in CPM. I think I mentioned this before. What we need is·an Input routine that reads the 'CNT' value. Even more simply, if cpm wrote to an output port, it could display the 'cnt' value to the terminal/serial. Any thoughts???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (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
It looks perfect!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 12/19/2009 6:49:26 AM GMT
All we are asking is that the FAT guy and the emulation can "borrow" SD card access from each other without tripping each other up.
As to why we want to do this. Easy, drop a file into FAT from the PC, put the SD into TriBlade, read the file into CP/M. No messing with odd tools etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (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
No luck yet.
I made a new disk format definition for the 8Mb HD in the diskdefs configuration file like so:
and the try for a directory listing with
$cpmls -f zicog i.dsk
Parameters for the disk from the dpb we have in zicog_cpm and the output of xformat.
Not sure if I'm interpreting maxdir correctly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.