Dr_Acula said...
That works. Looking at a common file we can work on, can you pls re-release that with the baud rate at 115k, and try the LF commented out.
I'll change those two things on my working file (and hopefully remember to change them if I upload a new package).
Then you can use the terminal you are using. (my inability to go above 38k baud speed is due to the long serial cable. 38k is more than fast enough for me!)
I must say that is is amazing watching xmodem work. Also, I know I said those 4 lines
'<== probably can speedup by enabling this
if blockno == 0
buff[noparse][[/noparse]0] := $C3 'force jmp to $FF00 (faster)
buff := $00
buff := $FF
didn't make a difference to the boot speed. They don't, but something has dramatically increased the speed of file writes when doing an xmodem file transfer.
All looking good!
So - on to the next phase. I've pondered all sorts of ways to get the bigger disk images, but keep coming back to heater's comment that it is best to keep this as a simh simulation. Use the simh standards. I was tempted at one stage earlier today to get into the cbios settings and make the floppy drives bigger, but I think heater is right. Keep the first 8 drives as 1mb, and then the next 4 as 8mb. Down the track, maybe we can get a link to the zicog on the simh site (as the N8VEM managed to do once it was stable).
Heater, I spent 4 months procrastinating building a triblade. Cluso was very patient, and he even sent me a freebie sd socket at one stage. So I know the board can be a bit daunting, but are you stuck with one particular part missing, or is the build a bit confusing? I know this might be a bit odd to hassle you like this, but I feel like a smoker who has just quit and now has gone all evangelical about it. The triblade is great!!! If you need a ram chip or something, pls let me know so I can send you one.
Was there a thought at one stage of using faster sd access code? Is this possible (it would be great if it is!)
Try CAT5/6 ethernet cable with db9 serial connectors at the end. I have run ~75m long serial at 115k. Sometimes could be a problem with some laptops (because of the power management some models have 3/5V levels on serial port) but should always work with desktops (+12/-12V levels (in the averege))
OK here is what we can do with CP/M hard disk emulation:
Drive I: has a file on it called ex8080.com, so I can delete it:
A> ERA I:EX8080.COM
Check that it is gone:
A> DIR I:EX8080.COM
Yep, "no file". So now we know we can write to the disk, directories at least.
Now put it back from A:
PIP I:=A:EX8080.COM
This results in lots of "hdsk write" messages and then CP/M crashes.
But after a reboot the file is back on I: and it runs OK.
I have the idea that my CP/M crashes after hard disk writes are due to the lack of memory available.
I seem to recall this requires a min of 24K and I have just 23K.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have probably done all I can on zicog for the next few days. I'd like to now post what I have which includes all of Dr_A's and Cluso's changes as ZiCog version 10 in the ZiCog thread.
Any last minute thoughts?
Would anyone like a hard disk drive image to go with it for testing on TriBlade ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Amazing - I go to sleep for 8 hours and look at what has happened. Does the sun never set on the Zicog project?
Ok, heater, heading over to that other thread now to check out the code.
Re disk images, they are 32mb so maybe a bit impractical to post. But Cluso has a vb6 program to create them. I had to modify it a bit so it makes the files in the current directory, not the specific directory he was using (which was on drive D and my computer doesn't have a drive D). But simple enough to do.
Re "What are you guys using for terminals? Don't tell me another Prop..."
Well, yes, I guess the PockeTerm is another prop. Also Teraterm/Hyperterminal. I prefer Teraterm because it boots up slightly faster. None of these give the double line problem. Re ^C, they just go down the line as the correct ascii code eg 03. No traps or special modifications for any control characters - they just go straight through. That was one of the mods for xmodem as xmodem does not treat any bytes as special. A few months ago we had some N8VEM boards online and people were logging in from overseas using Telnet. We are probably getting close to doing that with a Zicog too. Also, all these 'standard' terminal programs have xmodem built in.
Can't wait to test out the hard disk code!
And re cat5/6 cable for serial, I'll check it out.
Addit: heater, can you pls bump the zicog thread - it has been lost in the mists of time...
Post Edited (Dr_Acula) : 8/18/2009 11:59:31 PM GMT
Yes, please post the hard disk image. It should zip down pretty well.·Is it 512Bytes per SD sector and no extra bytes (like the 137 in floppy)?
Anyway, the blank disks already done for floppies can just be copied. Nice to keep them all 32MB so that we might expand them later??? Suggest we call them HDRIVE_I.DSK, HDRIVE_J.DSK, HDRIVE_K.DSK, HDRIVE_L.DSK
Terminals. I am using (was) PropTerminal. To remove the extra LF's you should just comment out the UART.tx(10) in the crlf routine in ZiCog_demo
James: No sleep for the wicked !!! re my VB6 program - you should have seen it before I posted it (full of old Smile and kludged code) ··
PS. Now a direct link to ZiCog & MoCog in my signature.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Dr_A: Does the sun go down on ZiCog?
Don't forget I'm in Finland, the sun soon going to be pretty much down for 6 months[noparse]:)[/noparse]
I have not posted the code yet, must clean up my files a bit.
As for terminals, I'm on Linux so no HyperTerminal/TeraTerm. The BST terminal window gives me a blank line, say between A> prompts, every time I hit return. In GtkTerm I can send $0D or $0A individually and then no blank lines.
So this is a terminal problem not a ZiCog proplem. I'll try minicom at some point.
Dr_A: "heater, can you pls bump the zicog thread - it has been lost in the mists of time..."
Check this out: Go to Google, enter "zicog", the ZiCog thread is the FIRST result returned!!!
We are THAT famous. Seems in the whole internet "zicog" only appears on 412 pages!
Re: My disk images: I'm using SIMH 8Mbyte HD disk images expanded to 32MB by placing each 128 byte sector into one 512byte SD block with each being padded by zeros. I actually create my 8 floppies and one HD as a single file that is written directly to the SD card (no FAT or partitions or such)
I can skip the floppies and just make the HD image if you are interested.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: re hard disk image - What files are on the hdisk? Can I just copy them from a floppy style drive? If so, I can use one of the blank copies and format, then pip to it. I posted a VB6 program here maybe a week or two ago that I use to make the disk files. They take 137 byte inputs though and create 128 bytes of the 512 byte sectors like you have in the end.
Nice re google You have made history then
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
For my hard disk I just used SIMH AltairZ80 to create a blank disk I: and then copied all the files from A: to I: just so as to have something on it. CP/M 2 is using 128 byte sectors for hard disks by default so I have a Python program that stretches the SIMH image file, 128 sector bytes every 512 byte SD block bytes in the output file.
Actually the Python program also stretches 8 floppy disk images, 137 sector bytes into 512 SD block bytes, and concatenates them and the hard disk image into a single output file.
That output file is then written to the SD card using the Linux dd command as raw blocks (no FAT or partitions).
The Python program, mk_zicog_image.py is included in the release of ZiCog that I have just now posted.
As for the Google results, it seems odd to me. "zicog" is such a short word, most 5 letter combinations turn up for something even if its just due to spelling mistakes. Before we turned up "zicog" only had 200 or so hits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: Do you convert the 137 bytes down to 128 in your conversion? Are they checked anywhere in CPM? I have been filling them in just in case. If we can ditch the 137 and go to 128 it would make things simpler for all of us.
Your hard disk image will be the same as mine then, so I can just format and pip files to it
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
No. I'm putting all 137 bytes of the floppy sector into 512 bytes of SD block with zero padding.
The spin floppy emulator just throws all those 137 bytes at the BIOS.
You have a good point if I understand correctly:
1) Make my floppy images as 128 bytes of "real" sector data per every 512 bytes of SD block.
2) Have the floppy emulation read those 128 bytes and add the pre and post junk bytes.
3) Pass the 137 bytes into the BIOS.
As you say we then have floppy disk images that can be used in DemoBoard or TriBlade.
Just in case of confusion, SIMH does NOT have any "junk" bytes in its hard disk sectors. Only the 128 real data bytes. Only floppies have the 137 bytes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Problem with unstable CP/M using 4 hard drives on TriBlade (and SIMH) resolved:
Peter Schorn has put me right regarding setting up 4 hard drives. Turns out that when one set nhdsks to 4 in CFGCCP.LIB the resulting CBIOSX is too big to fit into the memory space assigned to it in the rest of the system generation process. To accommodate the bigger BIOS one has to also set bioslen to 1000H in CFGCCP.LIB and change the line "SAVE 44 CPMBOOT.COM" to "SAVE 47 CPMBOOT.COM". Then do the syscpm2.
Had we been paying attention we would have noticed the warning message about this during the syscpm2 run.
Those two drives are costing us 768 bytes of RAM !!
For those in a hurry attached is a SIMH format disk built for 4 hard drives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I've been doing some experiments trying to get it to boot from a hard drive. Was heater working on this too?
Anyway, zicog currently appears to copy DRIVE_1M.DSK into ram. This binary file looks pretty straightforward as it starts with
C3 00 F2 00 00 C3 06 E4 00 00 00 00 00 00 00 00
I know it is a bit sad being able to read machine code from hex, but that is a jmp to F200 which makes sense. So, load in an image of 64k of ram, then start executing at the first byte.
So I tried recompiling on the altair simh. This appears to work and drive A is cpm2.dsk. But looking at the binary of the disk, the first line is
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
So, I'm not sure how the data is stored on the system tracks. Or even where the system tracks are.
The last line of the SYSCPM2.SUB batch file is
; write boot file to reserved tracks, must be last command
BOOTGEN CPMBOOT.COM A:
This writes a file to the system tracks. I managed to find the source for this program on the app.dsk
It is written in a language called SPL (simple programming language). This is a bit like C. To my eyes, and in a somewhat circular sort of way, it also looks awfully like Spin.
Anyway, this code contains a tantalising clue as to how the system tracks work
The sectors of a track are read in the following order:
first odd sectors, then even sectors in ascending order
1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,
2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32
T0[noparse][[/noparse]S9 - S32], T1, T2, T3, T4, T5[noparse][[/noparse]S1 - S24]
28 + 32+ 32+ 32+ 32+ 28 = 184 sectors = 23552 byte (5C00)
loads sectors to 0 .. 5bff and jumps to 0 when done
But I can't quite decode how it works. At the very least, it does not seem to be a 1:1 copy of the memory.
Has zicog got to the stage of booting from a floppy image where the floppy image boot tracks have been modified with BOOTGEN?
And, can I ask who created the DRIVE__1M.DSK?
Floppy and hard drives ?? have the same boot track geometry. (Though hard drives maybe have more space). Would booting off DRIVE__A.DSK, or indeed, DRIVE__I.DSK involve decoding the system track geometry in Spin.
Any help or advice would be appreciated. Or maybe this has already been cracked?
Yes I have been looking at booting from hard drive. Turns out to be very easy.
Yes we have been booting from CP/M laid down by BOOTGEN for a long time.
Here is an experiment you can do on SIMH to convince yourself of how booting from HD works.
1) Fire up SIMH into CP/M 2. Be sure you have "attach hdsk0 i.dsk" in your cpm2 command file first.
2) Rebuild CP/M 2 with "do syscpm2", be sure you first have at least 1 HD configured in CFGCCP.LIB
This step ensures you have HD enabled and produces a CPMBOOT.COM file.
3) Format your I drive with "xformat i" (optional)
4) Copy all your useful CP/M commands from A: to I: with "PIP I:=A:*.*"
5) Put CP/M system on the boot tracks of drive I with "BOOTGEN CPMBOOT.COM I:"
Actually the I: disk supplied with SIMH already is bootable but this is how to make it so.
6) Exit SIMH and edit your cpm2 command file such that the last line reads "boot hdsk0" instead of "boot dsk" or whatever.
7) Restart your SIMH and BINGO you are booted up from and logged into the I. drive.
Now how do we do this on the TriBlade ?
1) On SIMH assemble the HD boot loader HDSKBOOT.MAC to get HDSKBOOT.COM
2) Like DSKBOOT.COM this needs to be loaded into RAM prior to starting the emulation, we need both DSKBOOT and HDSKBOOT. It should be loaded at 5C00, if I remember correctly. So this HDSKBOOT.COM will need to be inserted into the RAM image file DRIVE_1M.RAM for TriBlade.
3) There is a byte in the DSKBOOT that determines the drive to boot from, I forget its offset now look in DSKBOOT.MAC.
This byte will need setting to 8, I believe, to select the I: disk.
4) The I: disk will need to have been BOOTGENed as above.
How does it work?
On start up the Z80 runs through RAM which is full of NOPs (zeros) until it hits the HDSKBOOT code at 5C00.
HDSKBOOT runs and finds out the desired boot device from the magic byte within DSKBOOT, which is at FF00.
HDSKBOOT then loads CP/M from that hard drive.
There is one catch: The HDSKBOOT as supplied uses some SIMH feature we don't have on TriBlade.
Just now i can't remeber what that was. Something to do with it asking the emulation, via the SIMHPORT, if banked memory is enabled. I think ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I managed to work out booting from hard disks on the simh yesterday.
But booting on the zicog is eluding me. Working through your instructions now. Looks a little complex - maybe we need to automate this somehow? I'll see how it goes...
Hmm - are we rewriting the file syscpm2.sub?
Maybe go back a step - has anyone managed to boot from a floppy disk image?
Post Edited (Dr_Acula) : 8/24/2009 12:35:31 PM GMT
Yikes, this is turning very complicated. First of all, booting to disk I on the SIMH seems to have a few bugs - using R and W hangs the simulation. So I've gone back to booting from A.
hdskboot.mac doesn't TYPE properly nor view in notepad, but you can view it by selecting all the text in notepad and then paste that into Word.
There is this little bit of code which does suggest it is not loading from sector 0:
firstSector equ 8 ; first sector to load
firstTrack equ 0 ; from this track
I had this idea that one could drop in a simh disk image with the system tracks already loaded and there would be enough information to boot from that. I guess we are looking for a boot eprom, and I think such a thing exists in the simh but I can't find its description. The altair simh c source is many files to search through.
Rebuilding the N8VEM is complicated too, especially when every part is packed together so when you add a few bytes to one bit of code it overwrites another bit. I ended up automating the whole process with the program below - which behind the scenes has pages of vb.net code. It even shells out to the simh via telnet at one stage. It does come down to a few clicks on boxes to make a new image and that is simple - just as running DO SYSCPM2 is a simple one step command on the simh.
I was trying to aim for simplicity by creating a 'boot rom' in Spin to read off the first few sectors and act on them. But even that could be complex as there will be different settings for hard and floppy disks.
So.... maybe go back to the system as it is. Boots by reading in an exact copy of the 64k of memory off a simple binary file DRIVE__1M.DSK
The only thing I have tweaked in Spin for that is to only read in 8 blocks instead of 128. Speeds up cold boots. And if I want to fill the ram disk, there are other ways to do that. Though I think there is a trend towards using the ram for banking anyway.
I'm leaning towards heater's philosophy on this - keep the simh as it is, 8 floppy drives, 2 hard drives. And boot from whatever is in DRIVE__1M (kudos to the author of that!).
HDSKBOOT.MAC has funny line endings, I view it in wordpad or kate on Linux.
SIMH dose have a boot ROM. It loads the DSKBOOT.COM into FF00 prior to starting. The code for DSKBOOT.COM is actually held in the C source of the floppy disk emulation as a bunch of data definition bytes. I forget the name of the disk driver emulation source.
Likewise the HDSKBOOT code is held in the hard disk driver emulation module.
I would recommend NOT creating a "boot rom" in Spin. Could be done but one has to read the sectors in a strange order and then doit differently for floppy or hard disks. We already have a floppy boot ROM working. It's DSKBOOT.COM and it is in that DRIVE__1M.DSK. Soon we will be able to put HDSKBOOT.COM into that file as well.
By the way DRIVE_1M.DSK is not any kind of disk image CP/M or otherwise. It is an image of the 64K RAM to set up prior to starting the emulation. With the DSKBOOT.COM sitting at FF00 and a few jumps setup at 0000 up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just managed to get reading and writing of packed Altair floppies working in ZiCog, 4 sectors per SD block.
Results:
Reads seem to go at about the same speed. No measurements just how it feels.
Writes are noticeably slower.
Disks are one quarter the size, duh.
Whats wrong?
Despite all my previous hand waving arguments about consecutive reads/writes benefiting from only having to read/write one SD block for every 4 sectors we have forgotten that CP/M, at least the BIOS, actively works against us.
CP/M has allocation blocks on disk. That is it works with files in chunks of sectors, say 1024 bytes worth, which would be great for ensuring a lot of sequential reads/writes.
BUT in an attempt to optimize the performance of real floppy drives it implements sector skewing. That is when accessing "logical" sectors 0, 1, 2, 3, 4... the BIOS goes to "physical" sectors on disk 01, 18, 03, 20.... or some other scheme. This is an attempt too allow the disk to spin around so that the next logical sector is under the head while the last sector is being processed.
This effort by the BIOS to ensure speedy sequential accesses of course is exactly the opposite of what we need and almost guarantees we never see sequential access to sectors within our SD card blocks.
Damn.
I will now get on with the packed hard disks. Luckily HDs don't use skewing and have large allocation blocks so sequential sector access should be the norm.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You can change the skew pretty easily in the CBIOSX. It is discussed in Johnson-Laird. I was thinking we would run into this - you got there before I could tell you.
WOW - I did the skew thing in 1975 on the mini's I worked on Could read every 2nd physical sector, but only write every 4th physical. Never thought it would be in CPM.
Heater, give the packed sectors a miss for now. We can always do it in V2.0. It is not a show stopper and for now it is fast enough. We have far better things to improve on than this. Later, it will be easy enough to determine whether the drive is packed or not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Clusso. I'm on a roll here, can't stop.
Thing is there is no skew problem with the hard disks plus hard disks have large allocation blocks, I forget how big just now.
Allocation blocks are consecutive sectors used as the minimum chunk size of a file and so should give rise to predominantly sequential access of sectors.
So again I'm curious to see if there is any performance boost from packed hard disk images disk images.
The way I see it, given that we have 4 large hard drives, and that floppies are always full, one would be working mostly in the hard disks. Maybe only using floppy images to import stuff from SIMH say.
So if floppy read speed is about the same who cares if we drop a bit of floppy write speed?
It's not much effort to do this, lets see how it goes, if it is a real dog we can drop it for now.
Are you up to giving the packed hard disks a test when I'm done, still need to take time out to build TriBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just for a lark I thought I would fire up MPM on the simh. 4 simultaneous users and banked memory.
Steps to do this:
Get MPM from http://www.schorn.ch/cpm/intro.php (about 1/4 of the way down) and put it in a directory
Copy the program ALTAIRZ80.COM into that directory (is on other packages but not in this one)
Create a little file (with notepad) called MPM.BAT and add this line :
altairz80 mpm
Run hyperterminal with a new session 'connect using TCP/IP' Leave the host address blank and use port 23
Type MPM<Ret> and it should scroll up some text.
Open hyperterminal again so both are running and do the same thing.
One will be user
0A>
and the other
1A>
Why bother?
Well, if we can drop in disk images for CP/M2, then we ought to be able to drop in other disk images. This is the simh compatability that heater talks about. Leave the disk images as they are and if you want something different (eg emulate a few ports from the N8VEM), add a few lines of spin code.
I have a reason for wanting this. I would like to be able to be running CP/M (or MP/M) on one board, and to be able to browse another board via wireless. Like Windows can. With a multi user system, one serial port could be the real port running whatever user programs one is running, and another serial port could be connected to a wireless transceiver (like we already have with xmodem) and in that user area one could have a simple program that autoboots and serves up files. A wireless file repository. I think that would be a really cool use for the zicog, with its huge file capacity and all.
But I'm a bit confused about something. I have books for MPM but non CPM3. MPM has banked memory, presumably for multi users. Is CP/M3 multi user? Is the banked memory in CP/M3 used for the same thing?
But a sanity check first - is this all crazy talk?
I'd love to see MP/M on a TriBlade. Are we going to need interrupts to make that work ?
CP/M 3 is not multi user but it can use banked memory. Basically it moves a load of its BIOS, BDOS, CCP stuff into one bank making room for a lot bigger TPA in another bank. I believe it is possible to shrink the "resident" part of CP/M down to a couple of K, just enough for the applications to make calls into then it bank switches to get the work done. So the TPA can be over 60K. Use of any other banks seems to be down to the applications to do as they will.
On SIMH and ZiCog we are using 48K banks and 16K resident area at the top of memory. It's fast and convenient that way.
CP/M 3 did not have time to catch on before it was run over by DOS/MicroSoft/IBM. So I guess books on it are thin on the ground.
MP/M extends this idea by having many banks and a TPA per user.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
Me, I'd never dream of such a thing...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
chers
Drive I: has a file on it called ex8080.com, so I can delete it:
A> ERA I:EX8080.COM
Check that it is gone:
A> DIR I:EX8080.COM
Yep, "no file". So now we know we can write to the disk, directories at least.
Now put it back from A:
PIP I:=A:EX8080.COM
This results in lots of "hdsk write" messages and then CP/M crashes.
But after a reboot the file is back on I: and it runs OK.
I have the idea that my CP/M crashes after hard disk writes are due to the lack of memory available.
I seem to recall this requires a min of 24K and I have just 23K.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I still get two line feeds when hitting return under the BST terminal or in gtkterm.
How are you getting Control-C, Control-Z and friends down the line ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Any last minute thoughts?
Would anyone like a hard disk drive image to go with it for testing on TriBlade ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ok, heater, heading over to that other thread now to check out the code.
Re disk images, they are 32mb so maybe a bit impractical to post. But Cluso has a vb6 program to create them. I had to modify it a bit so it makes the files in the current directory, not the specific directory he was using (which was on drive D and my computer doesn't have a drive D). But simple enough to do.
Re "What are you guys using for terminals? Don't tell me another Prop..."
Well, yes, I guess the PockeTerm is another prop. Also Teraterm/Hyperterminal. I prefer Teraterm because it boots up slightly faster. None of these give the double line problem. Re ^C, they just go down the line as the correct ascii code eg 03. No traps or special modifications for any control characters - they just go straight through. That was one of the mods for xmodem as xmodem does not treat any bytes as special. A few months ago we had some N8VEM boards online and people were logging in from overseas using Telnet. We are probably getting close to doing that with a Zicog too. Also, all these 'standard' terminal programs have xmodem built in.
Can't wait to test out the hard disk code!
And re cat5/6 cable for serial, I'll check it out.
Addit: heater, can you pls bump the zicog thread - it has been lost in the mists of time...
Post Edited (Dr_Acula) : 8/18/2009 11:59:31 PM GMT
Yes, please post the hard disk image. It should zip down pretty well.·Is it 512Bytes per SD sector and no extra bytes (like the 137 in floppy)?
Anyway, the blank disks already done for floppies can just be copied. Nice to keep them all 32MB so that we might expand them later??? Suggest we call them HDRIVE_I.DSK, HDRIVE_J.DSK, HDRIVE_K.DSK, HDRIVE_L.DSK
Terminals. I am using (was) PropTerminal. To remove the extra LF's you should just comment out the UART.tx(10) in the crlf routine in ZiCog_demo
James: No sleep for the wicked !!! re my VB6 program - you should have seen it before I posted it (full of old Smile and kludged code)
PS. Now a direct link to ZiCog & MoCog in my signature.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/19/2009 1:34:17 AM GMT
Don't forget I'm in Finland, the sun soon going to be pretty much down for 6 months[noparse]:)[/noparse]
I have not posted the code yet, must clean up my files a bit.
As for terminals, I'm on Linux so no HyperTerminal/TeraTerm. The BST terminal window gives me a blank line, say between A> prompts, every time I hit return. In GtkTerm I can send $0D or $0A individually and then no blank lines.
So this is a terminal problem not a ZiCog proplem. I'll try minicom at some point.
Dr_A: "heater, can you pls bump the zicog thread - it has been lost in the mists of time..."
Check this out: Go to Google, enter "zicog", the ZiCog thread is the FIRST result returned!!!
We are THAT famous. Seems in the whole internet "zicog" only appears on 412 pages!
Re: My disk images: I'm using SIMH 8Mbyte HD disk images expanded to 32MB by placing each 128 byte sector into one 512byte SD block with each being padded by zeros. I actually create my 8 floppies and one HD as a single file that is written directly to the SD card (no FAT or partitions or such)
I can skip the floppies and just make the HD image if you are interested.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Nice re google
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Actually the Python program also stretches 8 floppy disk images, 137 sector bytes into 512 SD block bytes, and concatenates them and the hard disk image into a single output file.
That output file is then written to the SD card using the Linux dd command as raw blocks (no FAT or partitions).
The Python program, mk_zicog_image.py is included in the release of ZiCog that I have just now posted.
As for the Google results, it seems odd to me. "zicog" is such a short word, most 5 letter combinations turn up for something even if its just due to spelling mistakes. Before we turned up "zicog" only had 200 or so hits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Your hard disk image will be the same as mine then, so I can just format and pip files to it
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 spin floppy emulator just throws all those 137 bytes at the BIOS.
You have a good point if I understand correctly:
1) Make my floppy images as 128 bytes of "real" sector data per every 512 bytes of SD block.
2) Have the floppy emulation read those 128 bytes and add the pre and post junk bytes.
3) Pass the 137 bytes into the BIOS.
As you say we then have floppy disk images that can be used in DemoBoard or TriBlade.
Just in case of confusion, SIMH does NOT have any "junk" bytes in its hard disk sectors. Only the 128 real data bytes. Only floppies have the 137 bytes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1 Yes
2 Yes but pre & post not required to be set
3 Pass 128 bytes into BIOS buffer +3
Then the only difference will be you are using 1 file the same as all my files (disks) concatenated and you don't use FAT16.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 me, the past is not over yet.
Peter Schorn has put me right regarding setting up 4 hard drives. Turns out that when one set nhdsks to 4 in CFGCCP.LIB the resulting CBIOSX is too big to fit into the memory space assigned to it in the rest of the system generation process. To accommodate the bigger BIOS one has to also set bioslen to 1000H in CFGCCP.LIB and change the line "SAVE 44 CPMBOOT.COM" to "SAVE 47 CPMBOOT.COM". Then do the syscpm2.
Had we been paying attention we would have noticed the warning message about this during the syscpm2 run.
Those two drives are costing us 768 bytes of RAM !!
For those in a hurry attached is a SIMH format disk built for 4 hard drives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Anyway, zicog currently appears to copy DRIVE_1M.DSK into ram. This binary file looks pretty straightforward as it starts with
C3 00 F2 00 00 C3 06 E4 00 00 00 00 00 00 00 00
I know it is a bit sad being able to read machine code from hex, but that is a jmp to F200 which makes sense. So, load in an image of 64k of ram, then start executing at the first byte.
So I tried recompiling on the altair simh. This appears to work and drive A is cpm2.dsk. But looking at the binary of the disk, the first line is
E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5
So, I'm not sure how the data is stored on the system tracks. Or even where the system tracks are.
The last line of the SYSCPM2.SUB batch file is
; write boot file to reserved tracks, must be last command
BOOTGEN CPMBOOT.COM A:
This writes a file to the system tracks. I managed to find the source for this program on the app.dsk
It is written in a language called SPL (simple programming language). This is a bit like C. To my eyes, and in a somewhat circular sort of way, it also looks awfully like Spin.
Anyway, this code contains a tantalising clue as to how the system tracks work
The sectors of a track are read in the following order:
first odd sectors, then even sectors in ascending order
1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,
2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32
T0[noparse][[/noparse]S9 - S32], T1, T2, T3, T4, T5[noparse][[/noparse]S1 - S24]
28 + 32+ 32+ 32+ 32+ 28 = 184 sectors = 23552 byte (5C00)
loads sectors to 0 .. 5bff and jumps to 0 when done
But I can't quite decode how it works. At the very least, it does not seem to be a 1:1 copy of the memory.
Has zicog got to the stage of booting from a floppy image where the floppy image boot tracks have been modified with BOOTGEN?
And, can I ask who created the DRIVE__1M.DSK?
Floppy and hard drives ?? have the same boot track geometry. (Though hard drives maybe have more space). Would booting off DRIVE__A.DSK, or indeed, DRIVE__I.DSK involve decoding the system track geometry in Spin.
Any help or advice would be appreciated. Or maybe this has already been cracked?
Working through this document at the moment simh.trailing-edge.com/pdf/altairz80_doc.pdf
... found a C3 00 F2 up at 680H. Not sure what it is doing there.
... found info in the simh documentation about the boot rom on page 8 of the above pdf.
Post Edited (Dr_Acula) : 8/24/2009 10:12:44 AM GMT
Yes I have been looking at booting from hard drive. Turns out to be very easy.
Yes we have been booting from CP/M laid down by BOOTGEN for a long time.
Here is an experiment you can do on SIMH to convince yourself of how booting from HD works.
1) Fire up SIMH into CP/M 2. Be sure you have "attach hdsk0 i.dsk" in your cpm2 command file first.
2) Rebuild CP/M 2 with "do syscpm2", be sure you first have at least 1 HD configured in CFGCCP.LIB
This step ensures you have HD enabled and produces a CPMBOOT.COM file.
3) Format your I drive with "xformat i" (optional)
4) Copy all your useful CP/M commands from A: to I: with "PIP I:=A:*.*"
5) Put CP/M system on the boot tracks of drive I with "BOOTGEN CPMBOOT.COM I:"
Actually the I: disk supplied with SIMH already is bootable but this is how to make it so.
6) Exit SIMH and edit your cpm2 command file such that the last line reads "boot hdsk0" instead of "boot dsk" or whatever.
7) Restart your SIMH and BINGO you are booted up from and logged into the I. drive.
Now how do we do this on the TriBlade ?
1) On SIMH assemble the HD boot loader HDSKBOOT.MAC to get HDSKBOOT.COM
2) Like DSKBOOT.COM this needs to be loaded into RAM prior to starting the emulation, we need both DSKBOOT and HDSKBOOT. It should be loaded at 5C00, if I remember correctly. So this HDSKBOOT.COM will need to be inserted into the RAM image file DRIVE_1M.RAM for TriBlade.
3) There is a byte in the DSKBOOT that determines the drive to boot from, I forget its offset now look in DSKBOOT.MAC.
This byte will need setting to 8, I believe, to select the I: disk.
4) The I: disk will need to have been BOOTGENed as above.
How does it work?
On start up the Z80 runs through RAM which is full of NOPs (zeros) until it hits the HDSKBOOT code at 5C00.
HDSKBOOT runs and finds out the desired boot device from the magic byte within DSKBOOT, which is at FF00.
HDSKBOOT then loads CP/M from that hard drive.
There is one catch: The HDSKBOOT as supplied uses some SIMH feature we don't have on TriBlade.
Just now i can't remeber what that was. Something to do with it asking the emulation, via the SIMHPORT, if banked memory is enabled. I think ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I managed to work out booting from hard disks on the simh yesterday.
But booting on the zicog is eluding me. Working through your instructions now. Looks a little complex - maybe we need to automate this somehow? I'll see how it goes...
Hmm - are we rewriting the file syscpm2.sub?
Maybe go back a step - has anyone managed to boot from a floppy disk image?
Post Edited (Dr_Acula) : 8/24/2009 12:35:31 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
hdskboot.mac doesn't TYPE properly nor view in notepad, but you can view it by selecting all the text in notepad and then paste that into Word.
There is this little bit of code which does suggest it is not loading from sector 0:
firstSector equ 8 ; first sector to load
firstTrack equ 0 ; from this track
I had this idea that one could drop in a simh disk image with the system tracks already loaded and there would be enough information to boot from that. I guess we are looking for a boot eprom, and I think such a thing exists in the simh but I can't find its description. The altair simh c source is many files to search through.
Rebuilding the N8VEM is complicated too, especially when every part is packed together so when you add a few bytes to one bit of code it overwrites another bit. I ended up automating the whole process with the program below - which behind the scenes has pages of vb.net code. It even shells out to the simh via telnet at one stage. It does come down to a few clicks on boxes to make a new image and that is simple - just as running DO SYSCPM2 is a simple one step command on the simh.
I was trying to aim for simplicity by creating a 'boot rom' in Spin to read off the first few sectors and act on them. But even that could be complex as there will be different settings for hard and floppy disks.
So.... maybe go back to the system as it is. Boots by reading in an exact copy of the 64k of memory off a simple binary file DRIVE__1M.DSK
The only thing I have tweaked in Spin for that is to only read in 8 blocks instead of 128. Speeds up cold boots. And if I want to fill the ram disk, there are other ways to do that. Though I think there is a trend towards using the ram for banking anyway.
I'm leaning towards heater's philosophy on this - keep the simh as it is, 8 floppy drives, 2 hard drives. And boot from whatever is in DRIVE__1M (kudos to the author of that!).
SIMH dose have a boot ROM. It loads the DSKBOOT.COM into FF00 prior to starting. The code for DSKBOOT.COM is actually held in the C source of the floppy disk emulation as a bunch of data definition bytes. I forget the name of the disk driver emulation source.
Likewise the HDSKBOOT code is held in the hard disk driver emulation module.
I would recommend NOT creating a "boot rom" in Spin. Could be done but one has to read the sectors in a strange order and then doit differently for floppy or hard disks. We already have a floppy boot ROM working. It's DSKBOOT.COM and it is in that DRIVE__1M.DSK. Soon we will be able to put HDSKBOOT.COM into that file as well.
By the way DRIVE_1M.DSK is not any kind of disk image CP/M or otherwise. It is an image of the 64K RAM to set up prior to starting the emulation. With the DSKBOOT.COM sitting at FF00 and a few jumps setup at 0000 up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Results:
Reads seem to go at about the same speed. No measurements just how it feels.
Writes are noticeably slower.
Disks are one quarter the size, duh.
Whats wrong?
Despite all my previous hand waving arguments about consecutive reads/writes benefiting from only having to read/write one SD block for every 4 sectors we have forgotten that CP/M, at least the BIOS, actively works against us.
CP/M has allocation blocks on disk. That is it works with files in chunks of sectors, say 1024 bytes worth, which would be great for ensuring a lot of sequential reads/writes.
BUT in an attempt to optimize the performance of real floppy drives it implements sector skewing. That is when accessing "logical" sectors 0, 1, 2, 3, 4... the BIOS goes to "physical" sectors on disk 01, 18, 03, 20.... or some other scheme. This is an attempt too allow the disk to spin around so that the next logical sector is under the head while the last sector is being processed.
This effort by the BIOS to ensure speedy sequential accesses of course is exactly the opposite of what we need and almost guarantees we never see sequential access to sectors within our SD card blocks.
Damn.
I will now get on with the packed hard disks. Luckily HDs don't use skewing and have large allocation blocks so sequential sector access should be the norm.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You can change the skew pretty easily in the CBIOSX. It is discussed in Johnson-Laird. I was thinking we would run into this - you got there before I could tell you.
Dave
Yes we can easily get rid of the skew. But then we hit that SIMH incompatibility problem again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater, give the packed sectors a miss for now. We can always do it in V2.0. It is not a show stopper and for now it is fast enough. We have far better things to improve on than this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Thing is there is no skew problem with the hard disks plus hard disks have large allocation blocks, I forget how big just now.
Allocation blocks are consecutive sectors used as the minimum chunk size of a file and so should give rise to predominantly sequential access of sectors.
So again I'm curious to see if there is any performance boost from packed hard disk images disk images.
The way I see it, given that we have 4 large hard drives, and that floppies are always full, one would be working mostly in the hard disks. Maybe only using floppy images to import stuff from SIMH say.
So if floppy read speed is about the same who cares if we drop a bit of floppy write speed?
It's not much effort to do this, lets see how it goes, if it is a real dog we can drop it for now.
Are you up to giving the packed hard disks a test when I'm done, still need to take time out to build TriBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Steps to do this:
Get MPM from http://www.schorn.ch/cpm/intro.php (about 1/4 of the way down) and put it in a directory
Copy the program ALTAIRZ80.COM into that directory (is on other packages but not in this one)
Create a little file (with notepad) called MPM.BAT and add this line :
altairz80 mpm
Run hyperterminal with a new session 'connect using TCP/IP' Leave the host address blank and use port 23
Type MPM<Ret> and it should scroll up some text.
Open hyperterminal again so both are running and do the same thing.
One will be user
0A>
and the other
1A>
Why bother?
Well, if we can drop in disk images for CP/M2, then we ought to be able to drop in other disk images. This is the simh compatability that heater talks about. Leave the disk images as they are and if you want something different (eg emulate a few ports from the N8VEM), add a few lines of spin code.
I have a reason for wanting this. I would like to be able to be running CP/M (or MP/M) on one board, and to be able to browse another board via wireless. Like Windows can. With a multi user system, one serial port could be the real port running whatever user programs one is running, and another serial port could be connected to a wireless transceiver (like we already have with xmodem) and in that user area one could have a simple program that autoboots and serves up files. A wireless file repository. I think that would be a really cool use for the zicog, with its huge file capacity and all.
But I'm a bit confused about something. I have books for MPM but non CPM3. MPM has banked memory, presumably for multi users. Is CP/M3 multi user? Is the banked memory in CP/M3 used for the same thing?
But a sanity check first - is this all crazy talk?
Addit: I've started documenting my wireless CP/M project here www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 8/25/2009 2:04:04 PM GMT
CP/M 3 is not multi user but it can use banked memory. Basically it moves a load of its BIOS, BDOS, CCP stuff into one bank making room for a lot bigger TPA in another bank. I believe it is possible to shrink the "resident" part of CP/M down to a couple of K, just enough for the applications to make calls into then it bank switches to get the work done. So the TPA can be over 60K. Use of any other banks seems to be down to the applications to do as they will.
On SIMH and ZiCog we are using 48K banks and 16K resident area at the top of memory. It's fast and convenient that way.
CP/M 3 did not have time to catch on before it was run over by DOS/MicroSoft/IBM. So I guess books on it are thin on the ground.
MP/M extends this idea by having many banks and a TPA per user.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.