David, Very nice detective work as I am sure this was bound to come up in some computer soon. I had the MyIDE rom in my system as well until we made the switch that allowed the boot from MasterZ80 so I would have seen the exact same thing had I not removed it.
Thanks again for all your valuable input, Thomas On Thursday, June 26, 2014 4:58:03 AM UTC-4, David Fry wrote: > > 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 >>>> >>>> -- You received this message because you are subscribed to the Google Groups "N8VEM-S100" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
