Hi Thomas,
I've found the cause of the problem :-)
It was a memory clash between CP/M and my MYIDEROM rom that was mapped to E000.
Trying to cut a long story short and to the best of my understanding at this point, the disk parameter tables contains various parameters that govern how CP/M accesses the disk, geometry, tables etc... One of the values that caught my eye in the DPH was the parameter ALV (see page 27 of the CP/M system guide) which is the scratchpad area for keeping track of disk allocation Mmmm...
Looking at the source code in HIDE3.ASM this value and others are not specified, so where are these values coming from ?.
The clue was that John mentioned in his webpage that there are a number of utilities/macros supplied by Digital Research that can be used to generate this information to make disk configuration easier. It turns out the utility involved is called GENCPM, this utility creates a file called GENCPM.DAT that holds much of the configuration information needed to build our CPM3.SYS file.
If you go to your source folder for generating CPM3.SYS and open up the file HMAKECPM.SUB you will notice an entry near the bottom GENCPM AUTO,
upon running this line if the file GENCPM.DAT exists then it will be used in the generation of the final CPM3.SYS file. If you now open the file GENCPM.DAT, the seventh entry down is 'MEMTOP = EF' this specifies the top of available memory for CP/M as EFFFH or EF00H (not sure)
My MYIDRROM EEPROM was mapped at E000 to EFFF, Ta Dah.....
I unplugged the EEPROM as I dont need it as a boot platform anymore, disabled the 8 bit chip select enable on the RAM/ROM board and after reloading my image onto the CF card, hey presto !!! all now working.
The lesson learned is that if you start inserting ROMS into your memory map you need to rebuild your CPM3.SYS file to take this into account by lowering the value of MEMTOP
Coming up against these sorts of problems is where you learn the most, there is still much more to learn.
I have included a couple of screenshots below of the same file copy operation (that previously failed) and a screenshot of the created directory entry
the green and blue boxes show the directory access as the file test.com is written to disk.
hope this may be of interest to you
regards
David Fry
On Wednesday, June 25, 2014 10:27:16 PM UTC+1, Thomas Owen wrote:
David,
How did you assemble this a particular image? Do you start with a blank CF and use the dummy file and cpmtools to write a .dsk? I bet you have already tried another CF...
The problem with this is that I learned most of what I know from you and your example work, so if you are stuck you can be assured I am!
Good luck,
Thomas
On Wednesday, June 25, 2014 3:04:22 PM UTC-4, David Fry wrote:
Hi Thomas,
It is only the last couple of weeks that have seen me getting the system this far, if you remember I stalled moving forward whilst waiting for a real time clock facility.
Anyway, looks like it may be software and not hardware,
For your own interest see the screenshot below
from the issuing of the command pip a:
test.com=a:
get.com we can see the following sectors accessed
1) LBA 41H is read (directory) to locate the program
pip.com (first green box) - CORRECT
2)
pip.com is read into memory LBA 1F0H to 200H - CORRECT
3)
pip.com then issues a directory read LBA 40H to find the sectors relating to
get.com - CORRECT
4)
get.com read into buffer LBA 148H to 154H -CORRECT
5)
pip.com reads the directory sector 44H into memory to add a directory entry, this is correct , last sector with entries in.
6) look like
pip.com then writes the direcotry back to sector 44H (note write command) - CORRECT
7) then
pip.com proceeds to write the buffer containing
get.com into sector 44H to 47H -
WRONG!!!
in fact with an emptier CF card image you can see that the directory entry is created but it allocates the first AU as 01H so based on that it writing to the correct location, question is why is it writing to AU 01H at all ??
8) the following green boxed area is where
CCP.COM is loaded back in before the command prompt returns.
Good Eh.... I'll let you know what it is when I track it down.
regards
David Fry
On Wednesday, June 25, 2014 5:51:31 PM UTC+1, Thomas Owen wrote:
Hello a David,
I wish I could help you but my system serial I/O is run from a Compupro system support 1 at 0D and 0C and I am not familiar with the propeller board at all.
I do tend to agree, it sounds like a hardware issue, but with all the work you did leading up to this with other images, did you ever see a 'write' go like this?
Good luck and let me know if I can help in any way.
Thomas