Yes, I think the problem will be the drive L parameter block as heater said.
I don't understand how you generate the extra hard drives under CPM - I don't need to anyway. But I was thinking overnight...(bad idea)
Should we increase to permit all 26 letter drives? Doesn't use much space does it (about 20 longs per drive)??
Next question - why are we using floppy emulation? Hard drives are quicker because of DMA aren't they? This would save code space and speed up. Now this then means each hard drive can be configured to specific parameters, so·one can be the ram disk which is a hell of a lot faster and we can configure it to be whatever size is free in sram. I should be able to even make the ram disk (tbp)·driver DMA it into the straight from one ram to another. Faster again
Next question - if the above is possible, then the ram disk should be able to be drive A: so all the CPM resides in ram - another dramatic speed improvement
Does any of this make sense. I think it should be easy - have I overlooked something????
Off in an hour and will not be around till either late tonight or tomorrow.
Postedit: James, can you try out the ramdisk to check it still works. (enable #define RamDisk and disable #define diskboot) I was looking at the code last night - this should still work and your A: drive will be the ramdisk and you will not be able to see the other drives. I just want to ensure it is still working before I make the ramdisk a full drive like the others. Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes, found where the error message is in cbiosx.mac
secmsg3:
db cr, lf, 'Must be a hard disk.', cr, lf, '$'
Working through the code.
Just a thought but there are enough changes now in the CPM2.DSK that we may need to re-release it. Eg number of hard drives, hard drive parameters on the cpm boot sector, plus essential files.
And if we do, then maybe we could get Peter to add it as a 'Zicog' version on the website?
Then perhaps think about what could be on the drive. I'm thinking of adding:
SUPERSUB.COM very useful expanded version of SUBMIT
XMODEMP.COM fundamental to downloaing
DIRX.COM a renamed version of an enhanced DIR program I found years ago that sorts alphabetically and gives the free space at the end.
Then - the hard drive parameter blocks.
Could we do something totally outrageous and make hard drives I to Y?
And make Z the ram drive?
or make R: the ram drive and still add lots more hard drives?
Hmm - hard drives for all. The useful thing about the floppies is they come as discrete packages on the simh site - eg wordstar on one, and basic on another. But - if they are slower...
What about rereleasing hard drive copies of each of those floppy drive images, so now the Wordstar disk has lots of free space on it?
A thought re Next question - if the above is possible, then the ram disk should be able to be drive A: so all the CPM resides in ram - another dramatic speed improvement
One thing I've absolutely needed on the N8VEM is the ability to run a batch file on boot. This is for remote boards that autorun programs if they are reset. So drive A needs to be permanent in some way. That would imply battery backup for the ram disk if one goes down that path. So - just a request, could the ram disk be something other than A?
@ heater - I'm a bit lost re why drive L should be different. This code seems to suggest it is the last floppy that is different, ie drive H. The hard drives are added in a loop so ought to be the same as each other:
Just posteditted after your post so here it is
James, can you try out the ramdisk to check it still works. (enable #define RamDisk and disable #define diskboot) I was looking at the code last night - this should still work and your A: drive will be the ramdisk and you will not be able to see the other drives. I just want to ensure it is still working before I make the ramdisk a full drive like the others. Thanks.
Just read your post - yes my idea also to use the ramdisk as drive A: (see my post above)
PS Ramdisk will be loaded from a disk/file on the SD (as it is now)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
James: The hdisk L: is in zicog_demo code where it defines the parameters. You will see the 4th drive has different parameters. Label dpb_3
re Ramdisk: it can be another drive - depends on zicog_demo where it will be. and you can save a copy onto its "other" SD image using pip, etc.
re existing Floppies: Do you know if the FAT (whatever cpm calls it) is the same or different for floppies vs hard drives, other than obviously the size. If we can make a hdp (hard disk parameter block) with the same parameters as a floppy then we may be able to have hard disks read floppies without software (all the speed, less code, and flexible). We can soft-configure the dpb's from an SD file
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Just did a little experiment re those dma on floppy vs hard drive.
Loading MBASIC off drive A (floppy) = 13 seconds.
Loading MBASIC off drive I (hard) = 4 seconds.
ok, tried that with the ram disk. There is a new drive A there now - looks like everything that is on DRIVE_1M.RAM
So that works.
Ok, so you are reading that file into ram and calling it drive A. That makes sense. Let's do that.
Only small catch is that trying to run a program like MBASIC gives an error reading from unimplemented port DB
But I am wondering - this is a 1meg disk image and I only have a 512k ram chip installed. So reads from any file in the second half of the directory are going to fail. ? need a ram disk image for boards with only one ram chip.
Drive A-ram?
Drive B-R = hard?
Drive T-Z=floppy?
Re re existing Floppies: Do you know if the FAT (whatever cpm calls it) is the same or different for floppies vs hard drives, other than obviously the size. If we can make a hdp (hard disk parameter block) with the same parameters as a floppy then we may be able to have hard disks read floppies without software (all the speed, less code, and flexible). We can soft-configure the dpb's from an SD file
sounds a bit complicated. I guess it is worth noting that you can always copy everything from any drive to any other drive with PIP
Re the ram drive, this is brilliantly fast on the N8VEM with programs loading almost instantly. So it ought to be fast on the zicog too. But I can't test it properly because I only have 512k. How are you creating that ram disk file - is that in the vb6 program?
Post Edited (Dr_Acula) : 8/21/2009 12:31:49 AM GMT
Ah, found the super 720k floppy thing - yes that is in spin.
Well, all the dpb blocks seem the same for hard drives. Is there a way of adding these to an array when adding more drives rather than repeating the data over and over?
Hmm - I'm going to change my mind about drive A being a ram disk. I just remembered back when ram disks first came out in dos, I installed one and it was cool for a while. But I started treating it like a disk drive and kept forgetting that the data was not saved permanently. So I'd turn the machine off and lose a whole lot of coding.
So - ram disks are useful for some purposes but I think they would only be useful as drive A (eg as it is on the N8VEM) if battery backed.
Just tried cp/m3 but I don't have a disk image nobank.
Post Edited (Dr_Acula) : 8/21/2009 12:42:14 AM GMT
Cluso, just going through some messages that no longer seem needed:
PRI in_hdskport_param
'Handle read from hdskport during disk parameters command
'Simply return the next param byte from a DPB.
'UART.str(string("hdskparam "))
'UART.dec(hdsk_reply_pos)
'UART.str(string(" = "))
io_data := hdsk_dpb[noparse][[/noparse]hdsk_reply_pos++]
io_data := BYTE[noparse][[/noparse]hdsk_dpb_ptr++]
hdsk_reply_pos++
'UART.hex(io_data,2)
'crlf
= 5 lines commented out
hdskWrite:
UART.str(string(".")) ' to indicated writing as this takes a while and looks like a hang
'crlf
changed a longer text message to just one "." and commented out the crlf. I might think about whether the "." is needed as well. It is handy at the moment as the system does look like it is hanging with big file copies. But then, lots of . in the middle of a wordstar save?? Of course, the whole thing might not be an issue with the new wizzo faster sd card access. I see that had high priority on the list of things to do.
PRI out_hdskport_param
'Handle writes to the hdskport when get params command is in progress
case hdsk_command_pos
1:
hdsk_drive := io_data
'UART.str(string("Hdsk drive = "))
'UART.dec(hdsk_drive)
'crlf
commented out three lines
PRI out_punstat
'Handle writes to the punch device command port
if io_data == creset
'UART.str(string("Punch reset"))
'crlf
commented out two lines
PRI out_constat
'Handle writes to the console command port
' perhaps need to add the byte value. ? where these come from
UART.str(string("Unknown console status write with byte &H"))
printhex(io_data)
crlf
Mabye a trap to skip if =03, or skip altogether?
I'm in the middle of really exercising the system with a copy of every file from drive A to drive I.
To do this with PIP, you must be in the source drive so A> and then
PIP I:=*.*
1) I'm not sure why the drive letters are limited to A: to L:. Is that a CP/M 2 limitation or a SIMH limitation.
2) Be aware that adding drives (floppy or hard) eats into CP/Ms memory for descriptors and buffers.
This may cause problems with some memory hungry programs. If required it would be better to do in CP/M 3 with banked memory.
3) I'm against adding drive letters, at least for now, as it also breaks SIMH compatibility as well as 2)
Re: ZiCog version of SIMH
I think this is a really weird idea. Asking Peter to support ZiCog in SIMH when all along I have been striving for SIMH compatibility seems like an admission of defeat or at least horribly cyclical.
Wanting a software emulation of a hardware platform to support another software emulation of the same platform which it self is based on the first....
Anyway I'm against it for now. Perhaps it would be reasonable when we have a rock solid working configuration.
Re: DPB blocks.
Yes we could have just one copy of the params for all hard drives but you know it's only 19 byes each.
It is possible we would like to have them different. As you see the drive L: has params for a 720K floppy which I one time though we could use for a RAM drive.
Actually the only reason for a RAM disk is speed, so having it as a hard drive using DMA may still be desirable as you showed the hard drive emulation is nearly 4 times faster!
What do you think?
Re: CPM3.
Attached are some cpm3 SIMH disk images.
Please can we stick to SIMH compatibility, at least for now. There is enough work just getting our Prop stuff working. When we have a rock solid version then may be play time with enhancements, BIOS rewrites, drive juggling etc.
For example, I'd like to see only two floppies A: and B: with the rest as hard drives. Possibly a RAM disk R:
This would require some seriously non SIMH compatible BIOS changes.
We should not expect Peter to want to support ZiCog/TriBlade until then, when we know exactly what our requirements are and have them working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
4 hard drives are getting closer but still getting some odd problems
I'm going to put this all in one place before I forget:
1) change spin code for dpb_3 to the code below, which deletes the other dpb3 and clones dpb2
2) Recompile simh drive A image so it uses 4 hard drives. Changed
nhdisks equ 4 ; total number of hard disks
in the file CFGCCP.LIB and then run SUPERSUB SYSCPM2
3) printout below of copying a file to drive L and then running it.
BUT - the catch. The recompile on the simh drive for 4 hard drives seems to corrupt drive A in some way. I've been trying to pin this bug down for a while because it doesn't show up immediately. But every time you do a DIR on drive A, more and more files disappear. Eventually there are only one or two left. Maybe it is overwriting the boot track or the list of files as there seem to be some bits in the binary image that have been set to zero. The problem shows up in the simh and on the zicog. The file was created on the simh - maybe I could try creating it on the zicog.
I was going to post a zip of the drive A with the boot tracks set to 4 drives, but I can't with this bug. So the attached drive A image is just a standard cpm2 one off the altair simh site, but with DIRX.COM, SUPERSUB.COM and XMODEMP.COM added.
So the answer is - yes we can have 4 hard drives but there is something not stable about the simh recompile process. I had this come up last night too but I couldn't pin it down. The missing files don't show up straight away - you have to use the drive for a while.
So - I'm going back to 2 hard drives for the moment. Maybe someone can try to replicate this?
As an aside, I think I agree with heater about keeping it similar to the simh. 8 floppies and two or 4 hard drives? In a way, having proved 4 drives are possible below, I'm actually content just to have 2 and keep it exactly the same as the simh image.
dpb_3 'Default 8MByte SIMH Altair HDSK params
:spt_low BYTE $20 'sectors per track (low byte)
:spt_high BYTE $00 'sectors per track (high byte)
:bsh BYTE $05 'data allocation Block SHift factor
:blm BYTE $1F 'data allocation block mask
:exm BYTE $01 'EXtent Mask
:dsm_low BYTE $F9 'maximum data block number (low_byte)
:dsm_high BYTE $07 'maximum data block number (high_byte)
:drm_low BYTE $FF 'total number of directory entries (low byte)
:drm_high BYTE $03 'total number of directory entries (high byte)
:al0 BYTE $FF 'determine reserved directory blocks
:al1 BYTE $00 'determine reserved directory blocks
:cks_low BYTE $00 'size of directory ChecK vector (low byte)
:cks_high BYTE $00 'size of directory ChecK vector (high byte)
:off_low BYTE $06 'number of reserved tracks (offset) (low byte)
:off_high BYTE $00 'number of reserved tracks (offset) (high byte)
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3
:ss_low BYTE $80 'Sector Size (low byte)
:ss_high BYTE $00 'Sector Size (high byte)
'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.
Dr_A, sounds like you are making excellent progress. The changes you describe seem quite fine.
Apart from the wonky drive A: behavior.
Is this true: "The problem shows up in the simh and on the zicog. The file was created on the simh - maybe I could try creating it on the zicog." ?
What are the exact steps you have taken to get to those disappearing files on SIMH.
Oh, I just downloaded a fresh new SIMH Altair Z80. Modified CFGCCP.LIB for 4 hard drives. Added the "attach" commands to cpm2. Then rebuilt it.
This gives some odd results straight away:
1) I can no longer use LS on drive A:
2) I can no longer "PIP I:=A:*.*" to copy files to I:
see here:
I>ls
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
DO $$$ 0K
1 File(s), occupying 0K of 8136K total capacity
1023 directory entries and 8136K bytes remain on I:
I>pip I:=a:mover.mac
I>ls
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
MOVER MAC 4K
1 File(s), occupying 4K of 8136K total capacity
1022 directory entries and 8132K bytes remain on I:
I>ls a:
Bdos Err On D: Bad Sector
Bdos Err On D: Bad Sector
Bdos Err On D: Bad Sector
64K CP/M Version 2.2 (SIMH ALTAIR 8800, BIOS V1.27, 4 HD, 02-May-2009)
A>
A>
This is a SIMH/CPM bug. We should probably report it to Peter. I will play with it a bit more and then do that if there is no obvious reason for this happening.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just back - sounds like you have made some reat progress and I agree with your drive comments to leave as per SIMH. If 4 hard drives are possible, then make the last one L: the Ram Disk. Retiring for the night so will be on tomorow
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
1) Good to see the 'disappearing files' problem replicated somewhere else - thanks heater. Looking back, this bug also would have been the cause of a number of crashes I had when debugging the zicog over the last 4 days - crashes which I attributed to things like a faulty sd card. Maybe no one has ever tried to add more hard drives?
2) CP/M3 boots up and eventually gets to the A> prompt after lots of writes to unimplemented port &HFD Takes a little while, but DIR is working etc. I had xmodemp copied over to drive B, so used PIP to copy it to drive A and tested it and it works fine. Downloaded DIRX.COM and ran that and it works fine to. Apart from commenting out that unimplemented port message (?what is it doing), I think we can declare CP/M3 working. Certainly no keyboard issues or missed keys and xmodem really tests that aspect of the serial port and it all works perfectly. CP/M is just a little slow compared with CP/M2.2 - is that due to the banking?
3) A question for Cluso (or any other spin experts)
'Memory Access Functions
'Read a "len" byte block given by "ramaddr" into hub at "hubaddr"
rdblock call #ram_open ' prepare for reading block
' returns with outa = ramaddr = -WE=1 -OE=1 LE=0 + address<<8
xor outa, ram_OE_bit ' -OE = 1 -> 0
nop ' sram delay (should not be reqd)
'rdloop wrbyte ina, bufadr ' <===== illegal - cannot use ina in wrxxxx instruction
rdloop mov outx, ina ' read byte from SRAM \ ignores upper bits
wrbyte outx, hubaddr ' copy byte to hub /
add hubaddr, #1 ' inc hub pointer
add outa, #(1 << 8) ' inc sram address
djnz len, #rdloop ' loop for xxx bytes
jmp #init
I've checked the specs and the ram chip is 55ns access. I see you just enable reads and then start incrementing the address. 55ns is approx 20Mhz, right? And the prop clocks at 80Mhz, and there are 5 instructions in the rdloop, so there is just enough time for the sram to settle before reading again? Tight timing, but it works. Amazing really!
I see one NOP in the write subroutine and there are a few more instructions, but this is quick enough to settle:?
I'm guessing you started off with longer delays and made it shorter and shorter? It seems quite amazing that the write works this fast. I guess the chips have to be close to each other. And, compared with real Z80 boards with multiple decoding logic in discrete chips, I guess there are no propogation delays. But amazing, nonetheless. The triblade is more cunning than it appears!
Leave the messages about unimplemented I/O ports for now. We should try and find out what they are.
Re: Faster SD access.
I believe Cluso wants to put in a new sd driver that will speed things up a bit.
Also when we go to 512 byte sector 32MB (or more) hard drives we automatically get a 4 times speed up don't we [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
James: The timing is calculated from the hardware specifications (proper engineering) not from trial and error. Remember I designed the board without a prototype. The nop instruction could be replaced with something useful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ah, if it is 4 clock cycles per instruction then that makes sense. I'm still thinking of ways to do the entire thing with one propeller chip. Lots of pins get spoken for - serial ports, programming, keyboard, vga. So it is 8 pins for a bus and a few pins for rd/wr/address. I think it ends up with 3 reads via latches for each read of a memory location rather than one and the emulation speed will go down. But offset against that could be a battery backed ramdisk which will read a lot faster than the sd card. Just pondering possibilities. Meanwhile, cluso have you got cp/m3 working yet?
Yoda has indicated he is willing to help also. Thanks Dave. He has a TriBlade, an N8VEM Z80 board, and has·designed the PropIO which connects to the Z80 & bus.
For the RamDisk, we will·need an hdp configuration to use it as a hard drive which is MUCH faster than a floppy drive. Here's what it requires:
Sector size: 128 Bytes for now. (can be 512 later·if it is faster)
Sectors per track: Suggest·32 if 128 byte sectors,·8 if 512. Total = 4KB
For the banking on CPM3 I just checked and we need 5 banks of 48KB and 16KB fixed. The banks are switched into the lowest 48KB ($0000-$BFF) of the 64KB Z80 Ram/Eprom space. Bank 0 is the default initialised bank. This gives a total memory requirement of 256KB and we use this as directly addressed sram on the prop. That is, we do the banking in software, not hardware.
The basics of this are already done, so I think it just a matter to test it.
Attached are 2 disks for CPM3 without bank switching. NONBANK3.DSK is the normal non-banked CPM3 and NONBNK3A.DSK is the non-banked CPM3 without sleep mode. Heater, do you remember what slep mode is??? These disks are in floppy format.
Yoda: I guess you will need to get your TriBlade up to our (nearest tested) latest code. This is posted on the ZiCog thread http://forums.parallax.com/showthread.php?p=788511·near the top of the page zicog010_demo_rr102......zip·The SD disk files are posted on the TriBlade thread on page 1 http://forums.parallax.com/showthread.php?p=786418·- you will require both microSD zip files. They must be contiguous files on the SD card.
Does this make sense???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Heater: I see you have asked Yoda some things on the N8VEM + Propeller thread.
I have been thinking. I presume we must have an A: floppy for boot purposes. Does anyone know if we save CPM space by removing the floppy support in CPM because it is otherwise pointless? The big thing will be to get 4 Hard Drives if possible because it would be nice for one of those to be the RamDrive as the DMA is soooo much faster.
Now, the RamDrive can just be a drive to do whatever. So, is there an Autoexec.bat equivalent in CPM? This could be used to automatically PIP whatever files are required on the RamDrive. Obviously files on the RamDrive will be lost on power fail or switchoff, so they have to be saved to a real drive (SD card) first!!! I have no plans for battery backup on my pcbs. I know from testing that powering down the pcb and then repowering it less than 30 seconds later that the data still remains in sram - no guarantees of this but that is what I found !!!
James: If you are around this evening I would like to get the RamDisk working as the second hard drive J:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Re the N8VEM's bios and the disks - drive A is 448k ram disk, B is a 16k eprom disk with essential files, C-E i think are hard drives (real physical ones) and F is for a large eprom disk.
The larger drives/sector sizes in CP/M3 sounds promising, now that CP/M3 is up and running.
I've got a N8VEM (actually 6 of them) alongside a triblade, so having them both working next to each other is great for cross fertilization of ideas.
eg the ramdisk is the key to the N8VEM's speed when loading and saving programs. One of the slow things I've noticed on the zicog is when exiting
out of a program back into CP/M. Is that because CP/M is being reloaded off the sd card? If so, maybe this could be loaded once at startup onto the ramdisk, and then reloaded off the ramdisk?
Also changing disks takes a long time - maybe there is a faster way of doing things there?
Addit; "So, is there an Autoexec.bat equivalent in CPM?'
Absolutely, and I have been using it for some time. It is a minor change to CP/M. When I get home from work I'll post the instructions on how to do it. Mine is called AUTOEXEC.SUB and as long as SUPERSUB exists on the drive it will run the batch file.
Mind you, if you don't want to patch CP/M, you could always 'type' a command into the serial input object at bootup so there are some characters and a CR in the buffer and when it gets to the A> prompt it processes those. So two solutions there.
It's great to have more hands on deck. (Hope your boat is big enough Cluso).
I'm shooting for 768KB RAM disk using the hard disk driver. For some reason that 720K definition we had as drive L: was rejected by CP/M. I'm looking into it.
I we sure we won't some need RAM for something else ?
Bank switching code is all in place. I thought I spotted a bug in it the other day but got distracted and now can't think what it might have been. Someone give it a good review.
Sleep mode is a SIMH a thing. BIOS accesses a "sleep" port in its serial port polling loop so that SIMH gets control and can do an operating system sleep() call. This prevents the simulator loop from using 100% CPU capacity.
We don't need it and I can't remember why I kept aversion of CPM/3 with it in.
I have a big SECRET which I was about to invite you to check out. We can boot CP/M from hard disk!!
So ultimately we don't need floppies at all. Unfortunately I can't test it without >24K RAM so its down to you.
I will supply the files for that today hopefully.
Yes we could probably save some CP/M RAM by removing floppy support. BUT I'm not keen as it would not be very much, we would lose the ability to just drop in SIMH prepared disks and as I keep saying can we please keep to SIMH compatibility at least for version 1.0. After that we can go nuts with BIOS hacking.
For example I am now reporting our wonky HD 4 problem to Perter Schorn. Assuming he fixes it we can just drop the new SIMH CPM/2, 3 in without having to fiddle with our own version as well.
Yes there is an AUTOEXEC mechanism in CP/M I have yet to figure it out though.
I'm writing a bug report for Peter re the 3rd and 4th hard disks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Don't waste too much time working out the autoexec, as I have it all written up at home (it took weeks of investigation, but was quite simple in the end). I'll be home in 2 hours and will post it then.
Re using the ram for different things, we can always have some ifdefs for different scenarios. eg 1 ram chip or 2 ram chips.
Heater: 720KB rejection could be something to do with the block or track size. 768KB = 512K+256K ??? Anyway, who cares if 768KB works.
If ram is needed for something else, we will worry about it then. Remember the next designs will only have 512KB total, not 1MB.
Great about possibly booting from the hard drive That will be MUCH faster. You have to build Blade #2 !!!!
Yes, I understand about keeping it standard SIMH CPM. If we can get 4 HD's then we don't need anything else anyway. We just define I: & J: as standard 8MB 128 byte sector drives (so we can copy anything that is around like the i.dsk), K: could be perhaps a 32MB 512B sector drive, and L: could be our RamDisk (size to vary depending of what is available). Meanwhile, will try J: as the RamDisk.
We can #define out support for floppies in spin code to save space (if required), such that if required we can drop it straight back in - this is only a problem for your minimal version to maximise the hub ram.
James: I expect CPM3 will be much faster with bank switching as I would think CPM will be loaded into one of the banks (or perhaps the 16KB resident section). User space then becomes 440KB 208KB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Could someone try a quick experiment on their TriBlade ?
In zicog_demo.spin replace the dpb_0 or (dpb_1) with the following and see if it comes up as a 720K drive hard drive I: or J:
dpb_0 '720K Super I/O Floppy, for use as RAM disk ?
:spt_low BYTE $24 'sectors per track (low byte)
:spt_high BYTE $00 'sectors per track (high byte)
:bsh BYTE $04 'data allocation Block SHift factor
:blm BYTE $0F 'data allocation block mask
:exm BYTE $00 'EXtent Mask
:dsm_low BYTE $62 'maximum data block number (low_byte)
:dsm_high BYTE $01 'maximum data block number (high_byte)
:drm_low BYTE $7E 'total number of directory entries (low byte)
:drm_high BYTE $00 'total number of directory entries (high byte)
:al0 BYTE $C0 'determine reserved directory blocks
:al1 BYTE $00 'determine reserved directory blocks
:cks_low BYTE $00 'size of directory ChecK vector (low byte)
:cks_high BYTE $00 'size of directory ChecK vector (high byte)
:off_low BYTE $02 'number of reserved tracks (offset) (low byte)
:off_high BYTE $00 'number of reserved tracks (offset) (high byte)
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $02 'Physical record SHift factor, CP/M 3
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $03 'PHhysical record Mask, CP/M 3
:ss_low BYTE $80 'Sector Size (low byte)
:ss_high BYTE $00 'Sector Size (high byte)
'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.
According to CBIOSX the cks_low and cks_high fields must be zero for non-removable media.
This inhibits some directory checking when swapping from drive to drive as CP/M then knows that the disk cannot have been changed. Which probably partially answers Dr_A's question about the sluggishness of loging into different drives.
If this works we have our RAM disk definition.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Home now. Ok, re autoexec files this is the first part of the cp/m source code for the N8VEM
The equivalent of #ifdef in this assembly is .EQU
There are lots of .EQUs at the beginning as there are now 12 different options. The option in question is CONDSUPERSUB
True is the original version of CP/M and false is the new version.
Scroll down the bottom for the examples of the two bits of code. Three changes
1) Add the text .DB "SUPERSUB AUTOEXEC"
.DB 0 ; zero at end
2) Add the number of bytes of this command, in this case 17
3) remove this number of zeros at the end of the inbuff so it adds up to the same number.
This then boots up and tries to run AUTOEXEC.SUB
If either AUTOEXEC.SUB or SUPERSUB.COM don't exist on the drive, it just gives an error and returns to the A> prompt.
Then just add a list of commands to AUTOEXEC.SUB
Ok, some more things got added to the thread while I was driving home. Off to check them out...
;**************************************************************
;*
;* C P / M VERSION 2 . 2
;*
;* RECONSTRUCTED FROM MEMORY IMAGE ON FEBRUARY 27, 1981
;*
;* BY CLARK A. CALKINS
;*
;**************************************************************
;
; SET MEMORY LIMIT HERE. THIS IS THE AMOUNT OF CONTIGEOUS
; RAM STARTING FROM 0000. CP/M WILL RESIDE AT THE END OF THIS SPACE.
; all instructions changed to .z80 mnemonics with XIZ.COM
; change dbgmonitor so it boots into cp/m directly
; changed 3 files on b drive
;
; add conditional assembly instructions here either .equ true or .equ false
; all conditional assembly groups start with CONDxxxx:
; default is true ie the original instructions eg .IF TSR is the original code
; so to add a new group set the name to false else set it to true for the old code
FALSE: .EQU 0
TRUE: .EQU ~FALSE
; list of conditional assembly instructions
CONDSWAPAB: .EQU FALSE ; true for original, false for new code=A=ram
CONDIDESOFT: .EQU FALSE ; if no ide drive, has a significant delay on soft boot (true) or quick (false)
CONDWBOOT: .EQU FALSE ; warm boot completely reloads cp/m (true) or doesn't (false)
CONDTSR .EQU FALSE ; true for original, false to add TSR routines
CONDSHORTMSG .EQU FALSE ; true for original warm boot signon, false for shorter one with less <CR>
CONDSUPERSUB .EQU FALSE ; true for no supersub autoexec, false to run supersub autoexec
CONDKEYBOARD .EQU FALSE ; true for original, false to scan PS2 keyboard in CONIN as well as serial
CONDCONOUT .EQU FALSE ; true for original, false to run echooff.com TSR to maintain radio silence and LCD
CONDUSRPATCH .EQU TRUE ; true for original, false to add A1> for user number as well as drive
CONDMASKCONIN .EQU FALSE ; true for original, false to add a >127 mask for conin
CONDABONLY .EQU FALSE ; true for original, false to only have drive A and B
CONDINVALIDDRV .EQU FALSE ; true for original, false to go to A if an invalid drive selected
; 22nd March, 2009 - added AND 127 to the uart input (2 places) so ignores rubbish characters from an xmodem fail
; see conin
; ***************** START OF CP/M CODE ****************************
MEM: .EQU 60 ; FOR A 62K SYSTEM (TS802 TEST - WORKS OK).
;
IOBYTE: .EQU 3 ; I/O DEFINITION BYTE.
TDRIVE: .EQU 4 ; CURRENT DRIVE NAME AND USER NUMBER.
ENTRY: .EQU 5 ; ENTRY POINT FOR THE CP/M BDOS.
TFCB: .EQU 5CH ; DEFAULT FILE CONTROL BLOCK.
TBUFF: .EQU 80H ; I/O BUFFER AND COMMAND LINE STORAGE.
TBASE: .EQU 100H ; TRANSIANT PROGRAM STORAGE AREA.
;
; SET CONTROL CHARACTER EQUATES.
;
CNTRLC: .EQU 3 ; CONTROL-C
CNTRLE: .EQU 05H ; CONTROL-E
BS: .EQU 08H ; BACKSPACE
TAB: .EQU 09H ; TAB
LF: .EQU 0AH ; LINE FEED
FF: .EQU 0CH ; FORM FEED
CR: .EQU 0DH ; CARRIAGE RETURN
CNTRLP: .EQU 10H ; CONTROL-P
CNTRLR: .EQU 12H ; CONTROL-R
CNTRLS: .EQU 13H ; CONTROL-S
CNTRLU: .EQU 15H ; CONTROL-U
CNTRLX: .EQU 18H ; CONTROL-X
CNTRLZ: .EQU 1AH ; CONTROL-Z (END-OF-FILE MARK)
DEL: .EQU 7FH ; RUBOUT
;
; SET ORIGIN FOR CP/M
;
.ORG (MEM-7)*1024
;
CBASE: JP COMMAND ; EXECUTE COMMAND PROCESSOR (CCP).
JP CLEARBUF ; ENTRY TO EMPTY INPUT BUFFER BEFORE STARTING CCP.
;
; STANDARD CP/M CCP INPUT BUFFER. FORMAT IS (MAX LENGTH),
; (ACTUAL LENGTH), (CHAR #1), (CHAR #2), (CHAR #3), ETC.
;
; conditional assembly for supersub
.IF CONDSUPERSUB
INBUFF: .DB 127 ; LENGTH OF INPUT BUFFER.
.DB 0 ; CURRENT LENGTH OF CONTENTS.
.DB "COPYRIGHT"
.DB " 1979 (C) BY "
.DB "DIGITAL RESEARCH "
.DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.ELSE
; modified code
INBUFF: .DB 127 ; LENGTH OF INPUT BUFFER.
; N8VEM - if add any text after this point, change db 0 below to length
; and put a 0 after the text, and delete the same number of zeros after the dig
; so that inpoint ends up at the same spot
; INBUFF+1 is cleared on the next warm boot, so only runs once.
.DB 17 ; Autoboot length of string
.DB "SUPERSUB AUTOEXEC"
.DB 0 ; zero at end
.DB "COPYRIGHT"
.DB " 1979 (C) BY "
.DB "DIGITAL RESEARCH "
.DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ; delete 6 zeros N8VEM
.DB 0,0,0 ; N8VEM now 3 zeros instead of 15 - comment out line above
.ENDIF
; back to unconditional assembly
Comments
I don't understand how you generate the extra hard drives under CPM - I don't need to anyway. But I was thinking overnight...(bad idea)
Should we increase to permit all 26 letter drives? Doesn't use much space does it (about 20 longs per drive)??
Next question - why are we using floppy emulation? Hard drives are quicker because of DMA aren't they? This would save code space and speed up. Now this then means each hard drive can be configured to specific parameters, so·one can be the ram disk which is a hell of a lot faster and we can configure it to be whatever size is free in sram. I should be able to even make the ram disk (tbp)·driver DMA it into the straight from one ram to another. Faster again
Next question - if the above is possible, then the ram disk should be able to be drive A: so all the CPM resides in ram - another dramatic speed improvement
Does any of this make sense. I think it should be easy - have I overlooked something????
Off in an hour and will not be around till either late tonight or tomorrow.
Postedit: James, can you try out the ramdisk to check it still works. (enable #define RamDisk and disable #define diskboot) I was looking at the code last night - this should still work and your A: drive will be the ramdisk and you will not be able to see the other drives. I just want to ensure it is still working before I make the ramdisk a full drive like the others. Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/20/2009 11:51:06 PM GMT
secmsg3:
db cr, lf, 'Must be a hard disk.', cr, lf, '$'
Working through the code.
Just a thought but there are enough changes now in the CPM2.DSK that we may need to re-release it. Eg number of hard drives, hard drive parameters on the cpm boot sector, plus essential files.
And if we do, then maybe we could get Peter to add it as a 'Zicog' version on the website?
Then perhaps think about what could be on the drive. I'm thinking of adding:
SUPERSUB.COM very useful expanded version of SUBMIT
XMODEMP.COM fundamental to downloaing
DIRX.COM a renamed version of an enhanced DIR program I found years ago that sorts alphabetically and gives the free space at the end.
Then - the hard drive parameter blocks.
Could we do something totally outrageous and make hard drives I to Y?
And make Z the ram drive?
or make R: the ram drive and still add lots more hard drives?
Attached are those programs.
Back to working through the biosx file
Addit: ha, I just read Cluso's crossed post!
What about rereleasing hard drive copies of each of those floppy drive images, so now the Wordstar disk has lots of free space on it?
A thought re Next question - if the above is possible, then the ram disk should be able to be drive A: so all the CPM resides in ram - another dramatic speed improvement
One thing I've absolutely needed on the N8VEM is the ability to run a batch file on boot. This is for remote boards that autorun programs if they are reset. So drive A needs to be permanent in some way. That would imply battery backup for the ram disk if one goes down that path. So - just a request, could the ram disk be something other than A?
@ heater - I'm a bit lost re why drive L should be different. This code seems to suggest it is the last floppy that is different, ie drive H. The hard drives are added in a loop so ought to be the same as each other:
; diskette drives ; dpbase equ $ dw atrans,0,0,0,dirbf,mits2,chk00,all00 dw atrans,0,0,0,dirbf,mits2,chk01,all01 dw atrans,0,0,0,dirbf,mits2,chk02,all02 dw atrans,0,0,0,dirbf,mits2,chk03,all03 dw atrans,0,0,0,dirbf,mits2,chk04,all04 dw atrans,0,0,0,dirbf,mits2,chk05,all05 dw atrans,0,0,0,dirbf,mits2,chk06,all06 dw atrans,0,0,0,dirbf,mits, chk07,all07 if nhdisks gt 0 defdw macro ?value dw all0&?value endm defdp macro ?number local ?hdi ?hdi defl 8 rept ?number dw 0,0,0,0,dirbf,simhd,0 defdw %?hdi ?hdi defl ?hdi+1 endm endmPost Edited (Dr_Acula) : 8/20/2009 11:55:00 PM GMT
James, can you try out the ramdisk to check it still works. (enable #define RamDisk and disable #define diskboot) I was looking at the code last night - this should still work and your A: drive will be the ramdisk and you will not be able to see the other drives. I just want to ensure it is still working before I make the ramdisk a full drive like the others. Thanks.
Just read your post - yes my idea also to use the ramdisk as drive A: (see my post above)
PS Ramdisk will be loaded from a disk/file on the SD (as it is now)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
re Ramdisk: it can be another drive - depends on zicog_demo where it will be. and you can save a copy onto its "other" SD image using pip, etc.
re existing Floppies: Do you know if the FAT (whatever cpm calls it) is the same or different for floppies vs hard drives, other than obviously the size. If we can make a hdp (hard disk parameter block) with the same parameters as a floppy then we may be able to have hard disks read floppies without software (all the speed, less code, and flexible). We can soft-configure the dpb's from an SD file
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Just did a little experiment re those dma on floppy vs hard drive.
Loading MBASIC off drive A (floppy) = 13 seconds.
Loading MBASIC off drive I (hard) = 4 seconds.
So that works.
Ok, so you are reading that file into ram and calling it drive A. That makes sense. Let's do that.
Only small catch is that trying to run a program like MBASIC gives an error reading from unimplemented port DB
But I am wondering - this is a 1meg disk image and I only have a 512k ram chip installed. So reads from any file in the second half of the directory are going to fail. ? need a ram disk image for boards with only one ram chip.
Drive A-ram?
Drive B-R = hard?
Drive T-Z=floppy?
Re re existing Floppies: Do you know if the FAT (whatever cpm calls it) is the same or different for floppies vs hard drives, other than obviously the size. If we can make a hdp (hard disk parameter block) with the same parameters as a floppy then we may be able to have hard disks read floppies without software (all the speed, less code, and flexible). We can soft-configure the dpb's from an SD file
sounds a bit complicated. I guess it is worth noting that you can always copy everything from any drive to any other drive with PIP
Re the ram drive, this is brilliantly fast on the N8VEM with programs loading almost instantly. So it ought to be fast on the zicog too. But I can't test it properly because I only have 512k. How are you creating that ram disk file - is that in the vb6 program?
Post Edited (Dr_Acula) : 8/21/2009 12:31:49 AM GMT
Well, all the dpb blocks seem the same for hard drives. Is there a way of adding these to an array when adding more drives rather than repeating the data over and over?
Hmm - I'm going to change my mind about drive A being a ram disk. I just remembered back when ram disks first came out in dos, I installed one and it was cool for a while. But I started treating it like a disk drive and kept forgetting that the data was not saved permanently. So I'd turn the machine off and lose a whole lot of coding.
So - ram disks are useful for some purposes but I think they would only be useful as drive A (eg as it is on the N8VEM) if battery backed.
Just tried cp/m3 but I don't have a disk image nobank.
Post Edited (Dr_Acula) : 8/21/2009 12:42:14 AM GMT
PRI in_hdskport_param 'Handle read from hdskport during disk parameters command 'Simply return the next param byte from a DPB. 'UART.str(string("hdskparam ")) 'UART.dec(hdsk_reply_pos) 'UART.str(string(" = ")) io_data := hdsk_dpb[noparse][[/noparse]hdsk_reply_pos++] io_data := BYTE[noparse][[/noparse]hdsk_dpb_ptr++] hdsk_reply_pos++ 'UART.hex(io_data,2) 'crlf= 5 lines commented out
hdskWrite: UART.str(string(".")) ' to indicated writing as this takes a while and looks like a hang 'crlfchanged a longer text message to just one "." and commented out the crlf. I might think about whether the "." is needed as well. It is handy at the moment as the system does look like it is hanging with big file copies. But then, lots of . in the middle of a wordstar save?? Of course, the whole thing might not be an issue with the new wizzo faster sd card access. I see that had high priority on the list of things to do.
PRI out_hdskport_param 'Handle writes to the hdskport when get params command is in progress case hdsk_command_pos 1: hdsk_drive := io_data 'UART.str(string("Hdsk drive = ")) 'UART.dec(hdsk_drive) 'crlfcommented out three lines
PRI out_punstat 'Handle writes to the punch device command port if io_data == creset 'UART.str(string("Punch reset")) 'crlfcommented out two lines
PRI out_constat 'Handle writes to the console command port ' perhaps need to add the byte value. ? where these come from UART.str(string("Unknown console status write with byte &H")) printhex(io_data) crlfMabye a trap to skip if =03, or skip altogether?
I'm in the middle of really exercising the system with a copy of every file from drive A to drive I.
To do this with PIP, you must be in the source drive so A> and then
PIP I:=*.*
Post Edited (Dr_Acula) : 8/21/2009 1:08:37 AM GMT
1) I'm not sure why the drive letters are limited to A: to L:. Is that a CP/M 2 limitation or a SIMH limitation.
2) Be aware that adding drives (floppy or hard) eats into CP/Ms memory for descriptors and buffers.
This may cause problems with some memory hungry programs. If required it would be better to do in CP/M 3 with banked memory.
3) I'm against adding drive letters, at least for now, as it also breaks SIMH compatibility as well as 2)
Re: ZiCog version of SIMH
I think this is a really weird idea. Asking Peter to support ZiCog in SIMH when all along I have been striving for SIMH compatibility seems like an admission of defeat or at least horribly cyclical.
Wanting a software emulation of a hardware platform to support another software emulation of the same platform which it self is based on the first....
Anyway I'm against it for now. Perhaps it would be reasonable when we have a rock solid working configuration.
Re: DPB blocks.
Yes we could have just one copy of the params for all hard drives but you know it's only 19 byes each.
It is possible we would like to have them different. As you see the drive L: has params for a 720K floppy which I one time though we could use for a RAM drive.
Actually the only reason for a RAM disk is speed, so having it as a hard drive using DMA may still be desirable as you showed the hard drive emulation is nearly 4 times faster!
What do you think?
Re: CPM3.
Attached are some cpm3 SIMH disk images.
Please can we stick to SIMH compatibility, at least for now. There is enough work just getting our Prop stuff working. When we have a rock solid version then may be play time with enhancements, BIOS rewrites, drive juggling etc.
For example, I'd like to see only two floppies A: and B: with the rest as hard drives. Possibly a RAM disk R:
This would require some seriously non SIMH compatible BIOS changes.
We should not expect Peter to want to support ZiCog/TriBlade until then, when we know exactly what our requirements are and have them working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm going to put this all in one place before I forget:
1) change spin code for dpb_3 to the code below, which deletes the other dpb3 and clones dpb2
2) Recompile simh drive A image so it uses 4 hard drives. Changed
in the file CFGCCP.LIB and then run SUPERSUB SYSCPM2
3) printout below of copying a file to drive L and then running it.
BUT - the catch. The recompile on the simh drive for 4 hard drives seems to corrupt drive A in some way. I've been trying to pin this bug down for a while because it doesn't show up immediately. But every time you do a DIR on drive A, more and more files disappear. Eventually there are only one or two left. Maybe it is overwriting the boot track or the list of files as there seem to be some bits in the binary image that have been set to zero. The problem shows up in the simh and on the zicog. The file was created on the simh - maybe I could try creating it on the zicog.
I was going to post a zip of the drive A with the boot tracks set to 4 drives, but I can't with this bug. So the attached drive A image is just a standard cpm2 one off the altair simh site, but with DIRX.COM, SUPERSUB.COM and XMODEMP.COM added.
So the answer is - yes we can have 4 hard drives but there is something not stable about the simh recompile process. I had this come up last night too but I couldn't pin it down. The missing files don't show up straight away - you have to use the drive for a while.
So - I'm going back to 2 hard drives for the moment. Maybe someone can try to replicate this?
As an aside, I think I agree with heater about keeping it similar to the simh. 8 floppies and two or 4 hard drives? In a way, having proved 4 drives are possible below, I'm actually content just to have 2 and keep it exactly the same as the simh image.
dpb_3 'Default 8MByte SIMH Altair HDSK params :spt_low BYTE $20 'sectors per track (low byte) :spt_high BYTE $00 'sectors per track (high byte) :bsh BYTE $05 'data allocation Block SHift factor :blm BYTE $1F 'data allocation block mask :exm BYTE $01 'EXtent Mask :dsm_low BYTE $F9 'maximum data block number (low_byte) :dsm_high BYTE $07 'maximum data block number (high_byte) :drm_low BYTE $FF 'total number of directory entries (low byte) :drm_high BYTE $03 'total number of directory entries (high byte) :al0 BYTE $FF 'determine reserved directory blocks :al1 BYTE $00 'determine reserved directory blocks :cks_low BYTE $00 'size of directory ChecK vector (low byte) :cks_high BYTE $00 'size of directory ChecK vector (high byte) :off_low BYTE $06 'number of reserved tracks (offset) (low byte) :off_high BYTE $00 'number of reserved tracks (offset) (high byte) [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $00 'Physical record SHift factor, CP/M 3 [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $00 'PHhysical record Mask, CP/M 3 :ss_low BYTE $80 'Sector Size (low byte) :ss_high BYTE $00 'Sector Size (high byte) 'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.Post Edited (Dr_Acula) : 8/21/2009 8:02:21 AM GMT
Apart from the wonky drive A: behavior.
Is this true: "The problem shows up in the simh and on the zicog. The file was created on the simh - maybe I could try creating it on the zicog." ?
What are the exact steps you have taken to get to those disappearing files on SIMH.
Oh, I just downloaded a fresh new SIMH Altair Z80. Modified CFGCCP.LIB for 4 hard drives. Added the "attach" commands to cpm2. Then rebuilt it.
This gives some odd results straight away:
1) I can no longer use LS on drive A:
2) I can no longer "PIP I:=A:*.*" to copy files to I:
see here:
This is a SIMH/CPM bug. We should probably report it to Peter. I will play with it a bit more and then do that if there is no obvious reason for this happening.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
With 2 hard drives everything seems fine, PIP I:=A:*.* works LS works....
Sounds like CBIOSX does allocate enough space for the buffers and such for more than 2 hard drives.
I will contact Peter about this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
2) CP/M3 boots up and eventually gets to the A> prompt after lots of writes to unimplemented port &HFD Takes a little while, but DIR is working etc. I had xmodemp copied over to drive B, so used PIP to copy it to drive A and tested it and it works fine. Downloaded DIRX.COM and ran that and it works fine to. Apart from commenting out that unimplemented port message (?what is it doing), I think we can declare CP/M3 working. Certainly no keyboard issues or missed keys and xmodem really tests that aspect of the serial port and it all works perfectly. CP/M is just a little slow compared with CP/M2.2 - is that due to the banking?
3) A question for Cluso (or any other spin experts)
'Memory Access Functions 'Read a "len" byte block given by "ramaddr" into hub at "hubaddr" rdblock call #ram_open ' prepare for reading block ' returns with outa = ramaddr = -WE=1 -OE=1 LE=0 + address<<8 xor outa, ram_OE_bit ' -OE = 1 -> 0 nop ' sram delay (should not be reqd) 'rdloop wrbyte ina, bufadr ' <===== illegal - cannot use ina in wrxxxx instruction rdloop mov outx, ina ' read byte from SRAM \ ignores upper bits wrbyte outx, hubaddr ' copy byte to hub / add hubaddr, #1 ' inc hub pointer add outa, #(1 << 8) ' inc sram address djnz len, #rdloop ' loop for xxx bytes jmp #initI've checked the specs and the ram chip is 55ns access. I see you just enable reads and then start incrementing the address. 55ns is approx 20Mhz, right? And the prop clocks at 80Mhz, and there are 5 instructions in the rdloop, so there is just enough time for the sram to settle before reading again? Tight timing, but it works. Amazing really!
I see one NOP in the write subroutine and there are a few more instructions, but this is quick enough to settle:?
xor outa, ram_WE_bit ' -WE= 1 -> 0 \\ write pulse nop ' sram delay || xor outa, ram_WE_bit ' -WE= 0 -> 1 //I'm guessing you started off with longer delays and made it shorter and shorter? It seems quite amazing that the write works this fast. I guess the chips have to be close to each other. And, compared with real Z80 boards with multiple decoding logic in discrete chips, I guess there are no propogation delays. But amazing, nonetheless. The triblade is more cunning than it appears!
4) Faster sd card access - is that possible?
Post Edited (Dr_Acula) : 8/21/2009 2:02:55 PM GMT
Leave the messages about unimplemented I/O ports for now. We should try and find out what they are.
Re: Faster SD access.
I believe Cluso wants to put in a new sd driver that will speed things up a bit.
Also when we go to 512 byte sector 32MB (or more) hard drives we automatically get a 4 times speed up don't we [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The clock is 80MHz but it takes 4 clocks to execute an instruction most of the time.
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
For the RamDisk, we will·need an hdp configuration to use it as a hard drive which is MUCH faster than a floppy drive. Here's what it requires:
For the banking on CPM3 I just checked and we need 5 banks of 48KB and 16KB fixed. The banks are switched into the lowest 48KB ($0000-$BFF) of the 64KB Z80 Ram/Eprom space. Bank 0 is the default initialised bank. This gives a total memory requirement of 256KB and we use this as directly addressed sram on the prop. That is, we do the banking in software, not hardware.
The basics of this are already done, so I think it just a matter to test it.
Attached are 2 disks for CPM3 without bank switching. NONBANK3.DSK is the normal non-banked CPM3 and NONBNK3A.DSK is the non-banked CPM3 without sleep mode. Heater, do you remember what slep mode is??? These disks are in floppy format.
Yoda: I guess you will need to get your TriBlade up to our (nearest tested) latest code. This is posted on the ZiCog thread http://forums.parallax.com/showthread.php?p=788511·near the top of the page zicog010_demo_rr102......zip·The SD disk files are posted on the TriBlade thread on page 1 http://forums.parallax.com/showthread.php?p=786418·- you will require both microSD zip files. They must be contiguous files on the SD card.
Does this make sense???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I have been thinking. I presume we must have an A: floppy for boot purposes. Does anyone know if we save CPM space by removing the floppy support in CPM because it is otherwise pointless? The big thing will be to get 4 Hard Drives if possible because it would be nice for one of those to be the RamDrive as the DMA is soooo much faster.
Now, the RamDrive can just be a drive to do whatever. So, is there an Autoexec.bat equivalent in CPM? This could be used to automatically PIP whatever files are required on the RamDrive. Obviously files on the RamDrive will be lost on power fail or switchoff, so they have to be saved to a real drive (SD card) first!!! I have no plans for battery backup on my pcbs. I know from testing that powering down the pcb and then repowering it less than 30 seconds later that the data still remains in sram - no guarantees of this but that is what I found !!!
James: If you are around this evening I would like to get the RamDisk working as the second hard drive J:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The larger drives/sector sizes in CP/M3 sounds promising, now that CP/M3 is up and running.
I've got a N8VEM (actually 6 of them) alongside a triblade, so having them both working next to each other is great for cross fertilization of ideas.
eg the ramdisk is the key to the N8VEM's speed when loading and saving programs. One of the slow things I've noticed on the zicog is when exiting
out of a program back into CP/M. Is that because CP/M is being reloaded off the sd card? If so, maybe this could be loaded once at startup onto the ramdisk, and then reloaded off the ramdisk?
Also changing disks takes a long time - maybe there is a faster way of doing things there?
Addit; "So, is there an Autoexec.bat equivalent in CPM?'
Absolutely, and I have been using it for some time. It is a minor change to CP/M. When I get home from work I'll post the instructions on how to do it. Mine is called AUTOEXEC.SUB and as long as SUPERSUB exists on the drive it will run the batch file.
Mind you, if you don't want to patch CP/M, you could always 'type' a command into the serial input object at bootup so there are some characters and a CR in the buffer and when it gets to the A> prompt it processes those. So two solutions there.
Post Edited (Dr_Acula) : 8/22/2009 9:17:44 AM GMT
I'm shooting for 768KB RAM disk using the hard disk driver. For some reason that 720K definition we had as drive L: was rejected by CP/M. I'm looking into it.
I we sure we won't some need RAM for something else ?
Bank switching code is all in place. I thought I spotted a bug in it the other day but got distracted and now can't think what it might have been. Someone give it a good review.
Sleep mode is a SIMH a thing. BIOS accesses a "sleep" port in its serial port polling loop so that SIMH gets control and can do an operating system sleep() call. This prevents the simulator loop from using 100% CPU capacity.
We don't need it and I can't remember why I kept aversion of CPM/3 with it in.
I have a big SECRET which I was about to invite you to check out. We can boot CP/M from hard disk!!
So ultimately we don't need floppies at all. Unfortunately I can't test it without >24K RAM so its down to you.
I will supply the files for that today hopefully.
Yes we could probably save some CP/M RAM by removing floppy support. BUT I'm not keen as it would not be very much, we would lose the ability to just drop in SIMH prepared disks and as I keep saying can we please keep to SIMH compatibility at least for version 1.0. After that we can go nuts with BIOS hacking.
For example I am now reporting our wonky HD 4 problem to Perter Schorn. Assuming he fixes it we can just drop the new SIMH CPM/2, 3 in without having to fiddle with our own version as well.
Yes there is an AUTOEXEC mechanism in CP/M I have yet to figure it out though.
I'm writing a bug report for Peter re the 3rd and 4th hard disks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Don't waste too much time working out the autoexec, as I have it all written up at home (it took weeks of investigation, but was quite simple in the end). I'll be home in 2 hours and will post it then.
Re using the ram for different things, we can always have some ifdefs for different scenarios. eg 1 ram chip or 2 ram chips.
If ram is needed for something else, we will worry about it then. Remember the next designs will only have 512KB total, not 1MB.
Great about possibly booting from the hard drive
Yes, I understand about keeping it standard SIMH CPM. If we can get 4 HD's then we don't need anything else anyway. We just define I: & J: as standard 8MB 128 byte sector drives (so we can copy anything that is around like the i.dsk), K: could be perhaps a 32MB 512B sector drive, and L: could be our RamDisk (size to vary depending of what is available). Meanwhile, will try J: as the RamDisk.
We can #define out support for floppies in spin code to save space (if required), such that if required we can drop it straight back in - this is only a problem for your minimal version to maximise the hub ram.
James: I expect CPM3 will be much faster with bank switching as I would think CPM will be loaded into one of the banks (or perhaps the 16KB resident section). User space then becomes 440KB 208KB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/22/2009 10:12:03 AM GMT
In zicog_demo.spin replace the dpb_0 or (dpb_1) with the following and see if it comes up as a 720K drive hard drive I: or J:
dpb_0 '720K Super I/O Floppy, for use as RAM disk ? :spt_low BYTE $24 'sectors per track (low byte) :spt_high BYTE $00 'sectors per track (high byte) :bsh BYTE $04 'data allocation Block SHift factor :blm BYTE $0F 'data allocation block mask :exm BYTE $00 'EXtent Mask :dsm_low BYTE $62 'maximum data block number (low_byte) :dsm_high BYTE $01 'maximum data block number (high_byte) :drm_low BYTE $7E 'total number of directory entries (low byte) :drm_high BYTE $00 'total number of directory entries (high byte) :al0 BYTE $C0 'determine reserved directory blocks :al1 BYTE $00 'determine reserved directory blocks :cks_low BYTE $00 'size of directory ChecK vector (low byte) :cks_high BYTE $00 'size of directory ChecK vector (high byte) :off_low BYTE $02 'number of reserved tracks (offset) (low byte) :off_high BYTE $00 'number of reserved tracks (offset) (high byte) [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]sh BYTE $02 'Physical record SHift factor, CP/M 3 [img]http://forums.parallax.com/images/smilies/tongue.gif[/img]hm BYTE $03 'PHhysical record Mask, CP/M 3 :ss_low BYTE $80 'Sector Size (low byte) :ss_high BYTE $00 'Sector Size (high byte) 'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.According to CBIOSX the cks_low and cks_high fields must be zero for non-removable media.
This inhibits some directory checking when swapping from drive to drive as CP/M then knows that the disk cannot have been changed. Which probably partially answers Dr_A's question about the sluggishness of loging into different drives.
If this works we have our RAM disk definition.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The equivalent of #ifdef in this assembly is .EQU
There are lots of .EQUs at the beginning as there are now 12 different options. The option in question is CONDSUPERSUB
True is the original version of CP/M and false is the new version.
Scroll down the bottom for the examples of the two bits of code. Three changes
1) Add the text .DB "SUPERSUB AUTOEXEC"
.DB 0 ; zero at end
2) Add the number of bytes of this command, in this case 17
3) remove this number of zeros at the end of the inbuff so it adds up to the same number.
This then boots up and tries to run AUTOEXEC.SUB
If either AUTOEXEC.SUB or SUPERSUB.COM don't exist on the drive, it just gives an error and returns to the A> prompt.
Then just add a list of commands to AUTOEXEC.SUB
Ok, some more things got added to the thread while I was driving home. Off to check them out...
;************************************************************** ;* ;* C P / M VERSION 2 . 2 ;* ;* RECONSTRUCTED FROM MEMORY IMAGE ON FEBRUARY 27, 1981 ;* ;* BY CLARK A. CALKINS ;* ;************************************************************** ; ; SET MEMORY LIMIT HERE. THIS IS THE AMOUNT OF CONTIGEOUS ; RAM STARTING FROM 0000. CP/M WILL RESIDE AT THE END OF THIS SPACE. ; all instructions changed to .z80 mnemonics with XIZ.COM ; change dbgmonitor so it boots into cp/m directly ; changed 3 files on b drive ; ; add conditional assembly instructions here either .equ true or .equ false ; all conditional assembly groups start with CONDxxxx: ; default is true ie the original instructions eg .IF TSR is the original code ; so to add a new group set the name to false else set it to true for the old code FALSE: .EQU 0 TRUE: .EQU ~FALSE ; list of conditional assembly instructions CONDSWAPAB: .EQU FALSE ; true for original, false for new code=A=ram CONDIDESOFT: .EQU FALSE ; if no ide drive, has a significant delay on soft boot (true) or quick (false) CONDWBOOT: .EQU FALSE ; warm boot completely reloads cp/m (true) or doesn't (false) CONDTSR .EQU FALSE ; true for original, false to add TSR routines CONDSHORTMSG .EQU FALSE ; true for original warm boot signon, false for shorter one with less <CR> CONDSUPERSUB .EQU FALSE ; true for no supersub autoexec, false to run supersub autoexec CONDKEYBOARD .EQU FALSE ; true for original, false to scan PS2 keyboard in CONIN as well as serial CONDCONOUT .EQU FALSE ; true for original, false to run echooff.com TSR to maintain radio silence and LCD CONDUSRPATCH .EQU TRUE ; true for original, false to add A1> for user number as well as drive CONDMASKCONIN .EQU FALSE ; true for original, false to add a >127 mask for conin CONDABONLY .EQU FALSE ; true for original, false to only have drive A and B CONDINVALIDDRV .EQU FALSE ; true for original, false to go to A if an invalid drive selected ; 22nd March, 2009 - added AND 127 to the uart input (2 places) so ignores rubbish characters from an xmodem fail ; see conin ; ***************** START OF CP/M CODE **************************** MEM: .EQU 60 ; FOR A 62K SYSTEM (TS802 TEST - WORKS OK). ; IOBYTE: .EQU 3 ; I/O DEFINITION BYTE. TDRIVE: .EQU 4 ; CURRENT DRIVE NAME AND USER NUMBER. ENTRY: .EQU 5 ; ENTRY POINT FOR THE CP/M BDOS. TFCB: .EQU 5CH ; DEFAULT FILE CONTROL BLOCK. TBUFF: .EQU 80H ; I/O BUFFER AND COMMAND LINE STORAGE. TBASE: .EQU 100H ; TRANSIANT PROGRAM STORAGE AREA. ; ; SET CONTROL CHARACTER EQUATES. ; CNTRLC: .EQU 3 ; CONTROL-C CNTRLE: .EQU 05H ; CONTROL-E BS: .EQU 08H ; BACKSPACE TAB: .EQU 09H ; TAB LF: .EQU 0AH ; LINE FEED FF: .EQU 0CH ; FORM FEED CR: .EQU 0DH ; CARRIAGE RETURN CNTRLP: .EQU 10H ; CONTROL-P CNTRLR: .EQU 12H ; CONTROL-R CNTRLS: .EQU 13H ; CONTROL-S CNTRLU: .EQU 15H ; CONTROL-U CNTRLX: .EQU 18H ; CONTROL-X CNTRLZ: .EQU 1AH ; CONTROL-Z (END-OF-FILE MARK) DEL: .EQU 7FH ; RUBOUT ; ; SET ORIGIN FOR CP/M ; .ORG (MEM-7)*1024 ; CBASE: JP COMMAND ; EXECUTE COMMAND PROCESSOR (CCP). JP CLEARBUF ; ENTRY TO EMPTY INPUT BUFFER BEFORE STARTING CCP. ; ; STANDARD CP/M CCP INPUT BUFFER. FORMAT IS (MAX LENGTH), ; (ACTUAL LENGTH), (CHAR #1), (CHAR #2), (CHAR #3), ETC. ; ; conditional assembly for supersub .IF CONDSUPERSUB INBUFF: .DB 127 ; LENGTH OF INPUT BUFFER. .DB 0 ; CURRENT LENGTH OF CONTENTS. .DB "COPYRIGHT" .DB " 1979 (C) BY " .DB "DIGITAL RESEARCH " .DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 .DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 .DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 .DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 .ELSE ; modified code INBUFF: .DB 127 ; LENGTH OF INPUT BUFFER. ; N8VEM - if add any text after this point, change db 0 below to length ; and put a 0 after the text, and delete the same number of zeros after the dig ; so that inpoint ends up at the same spot ; INBUFF+1 is cleared on the next warm boot, so only runs once. .DB 17 ; Autoboot length of string .DB "SUPERSUB AUTOEXEC" .DB 0 ; zero at end .DB "COPYRIGHT" .DB " 1979 (C) BY " .DB "DIGITAL RESEARCH " .DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 .DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 .DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ; delete 6 zeros N8VEM .DB 0,0,0 ; N8VEM now 3 zeros instead of 15 - comment out line above .ENDIF ; back to unconditional assemblytesting with a new disk image now...
Fixed these two lines
but still just returns to I> when you try to run a program
Post Edited (Dr_Acula) : 8/22/2009 11:46:14 AM GMT