Ok, getting there. I worked out pin 24 of the ram chip goes to pin 37 on the propeller
I have the latch fitted.
I didn't understand that the wire from pin 11 to pin 17 on the latch must not be fitted if the latch is present. I should have spotted that the holes on the photo don't have solder in them.
Re "the modification described in the errata item 5 (on thread page 6), MUST be done..." Could you give the date and time of the relevant post as I'm having trouble finding that one.
Hi Cluso. Thanks for the update. For some reason the scan won't rotate 90 degrees. So my neck is feeling decidedly wobbly...
Just to summarise in Plain English:
1) Pin 24 of the ram chip is removed from the socket and goes to pin 37 of the propeller.
2) pin 22 of the ram chip *still* goes to pin 17 of the latch AND there is no link between pin 11 and pin 17 on the latch?
1) Unzip to a new folder
2) copy all the .dsk files to the sd card
3) copy ziboot.com to the sd card
4) copy zicog__2.ptr to the sd card (?not needed but it failed when not there)
5) To edit the program, double click zicog_cpm_rc5.5b_rr120.spin and edit in the standard prop tool.
6) To download, shrink the prop tool. Keep the directory open. Double click BST.BAT
7) It should compile, find the prop, and download and run teraterm and boot up
8) To re-edit, close teraterm.
Comments:
1) I'm running at 38k baud. You can change teraterm to faster and you can change the .spin code to faster. Search 38_400
2) I'm running v120 but have the disks very slightly different for disk E and F I think. This package is complete though. Cluso is changing some of the disk images around
3) I've just dumped all the teraterm files into the working directory so they are all in one place.
4) I removed the 3 sec delay on startup. teraterm doesn't need it.
5) Each update from Cluso, I copy all the files to a new directory and change the BST.BAT file to reflect the new .spin file
6) I have a copy of the altair simh if you want that.
7) This still has the bug copying big files. Maybe you can help out on that one??
Going off on a tangent, one of the things I've found invaluable when writing actual CP/M code is some sort of integrated development environment. I'm very excited to announce that with the latest speedups that Heater and Cluso have managed to make, the IDE for the N8VEM now also works for the Zicog. This is a terminal program amongst other things, but it also allows downloads of packages of files, using a fast version of xmodem called xmodemf.com
So - I used teraterm to download xmodemf.com using the propeller version xmodemp.com.
Now one can send all the wordstar package, or the sbasic package in one go. So easy!
Better still, one can use the IDE for sbasic or BDSC or Assembly, with the copy and paste function and the coloured code etc.
And, it compiles on the board. And it is FAST!!! This is a screen capture of the program running on the triblade. Ok, I cheated a little and wrote the actual program on the PC using the N8VEM IDE (though I could have written it using notepad, or even wordstar [noparse][[/noparse]very soon once that bug is squisheed] on the triblade).
A>type new.bas
comment
call small procedures first then bigger procedures
as can't call/reference a later procedure (one pass compiler)
Dim common variables eg arrays at beginning of program
end
rem *** functions and procedures ***
rem ************ MAIN **************
print "Hello World"
end
A>
A>sbasic new
tm
S-BASIC Compiler Version 5.4b
.0001:00 comment
0002:01 call small procedures first then bigger procedures
0003:01 as can't call/reference a later procedure (one pass compiler)
0004:01 Dim common variables eg arrays at beginning of program
0005:01 end
0006:00 rem *** functions and procedures ***
0007:00
0008:00 rem ************ MAIN **************
0009:00
0010:00 print "Hello World"
0011:00 end
0012:00 ****** End of program ******
...........................Compilation complete
A>new
Hello World
A>
Cluso: After a little fight with BST that package of yours seems to work OK on the Demo Board.
Are you and Dr_A now in agreement that there is a bug with copying big files?
I have yet to see it on the Demo Board. Perhaps an external RAM access issue, perhaps something in the BIOS that shows up when built for 64K. Mysterious.
I think it might be wise to get rid of all those strange disk image file names in zicog_cpm.spin and just settle on something simple like "zicog_a.dsk, zicog_b.dsk" etc. People can always copy what ever images they have to those names on the SD card. These are really names for the virtual drive hardware rather than actual floppies (or HDs)
Are you desirous of having the floppy drive hardware support back in permanently? It makes an awful mess.
Still trying to construct a TriBlade here, but even on a Sunday real work gets in the way[noparse]:([/noparse]
Hope to pick up some more parts tomorrow though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A little more info on the bug....
1) 25K works correctly on TriBlade with 64KB sram (both Z80 & 8080) & ZIPM2_64.DSK
I need to recheck your latest build of 64KB version (not sure if I have the latest).
re Floppy drives. Please leave code there until we are ready for the v1.0 release. It is useful to create hdrives from floppies.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Wordstar hard disk attached. This is working on the simh, but it doesn't seem to work properly on the zicog.
A quick question - are altair simh hard drives compatible with zicog drives?
If yes, then TYPE on a text file should work. But it doesn't. Try TYPE WSPRINT.TST and it should print some text (works on the simh) but it types rubbish characters and eventually crashes.
There are two ways to make a hard drive file on the zicog.
1) Copy an altair simh hard drive file (? does this work)
2) PIP *.* from a floppy drive image. (not working on all files due to the 'big file' bug)
So - 1) doesn't seem to work so I tried 2) and is how I found the big file bug in the first place. So - making a wordstar hard drive image is not possible right now!
Maybe there is an incompatability issue between altair and zicog hard drive images and since they seem so close (DIR partially works for instance), it would be worth working out a way. So I'm posting this file and maybe someone can replicate this problem.
Addit: Something is definitely wrong with the drive image. LS displays all the files but DIR leaves about half out:
G>LS
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
VIDATT Z80 2K ! WSCHANGEOVR 12K ! WSPRINT OVR 74K ! WSU COM 4K
WS COM 4K ! WSCHHELPOVR 16K ! WSPRINT TST 4K
WS OVR 26K ! WSHELP OVR 14K ! WSREADMETXT 16K
WSCHANGECOM 18K ! WSMSGS OVR 8K ! WSSHORT OVR 2K
13 File(s), occupying 200K of 984K total capacity
236 directory entries and 784K bytes remain on G:
G>DIR
G: VIDATT Z80 : WSMSGS OVR : WSPRINT TST : WSSHORT OVR
G: WSU COM : WS COM
G>
Drac: Our hard disks are compatible with SIMH. For pip to work with floppies you have to compile with floppy support (unless you mean on SIMH which will work), although we are going to remove this for V1.0. We will just keep a version in the background that can do this.
PIP of files >28K (probably 32K) fails. I have seen other failures which are possibly due to the same bug, whatever it is. When I pip a 40K file it recovers after the garbage which is fairly consistent, but the file copied is corrupted.
I thought it may have been a conflict with the sram on triblade, but all the calls out of ZiCog Pasm to the upper spin code seem to have the correct bus release statements. The 25K version of CPM2.2 does pip correctly.
Drac, Do you remember I spoke of an additional chip... Well, I have just found a way in software to achieve the same speed increase without it :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Hmm - more experiments are needed. I need to eat dinner, then I'm going to start with a blank hard drive on the simh and copy one file across. Then do the same on the zicog and then compare the binary images.
Take a blank drive image on the simh and then on the zicog and PIP a single file from drive A.
Two screenshots of the two files side by side in a hex editor. Zicog at the top. SIMH at the bottom.
First difference is in the FCB with a byte 04 vs 08. This is the first byte of the disk allocation map so maybe there is something different in the disk parameters?
Second difference is the location of the data - at 8000 vs E000, which probably reflects the different disk allocation map.
Is heater around? There are so many programs not working on the hard drives (that were working before) and I think we need his expert opinion about where to begin. I was thinking about taking drive images with lots of files and comparing the binaries with the simh, but got stuck on the first file. So next plan is to start putting UART.str comments through the spin code and try to track it down that way. Back to coding...
Might be worth compiling with the floppies and see if that works. Not sure if I will get time tonight.
It seems to be just the 64K build causing problems.
Drac: Will the programs that fail run in 25K. If so, can you compile this version (uses ZIPM2.DSK - see the FindDriveBase section) and try the programs ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Not sure about how to compile with ZIPM2.DSK, can you pls explain that one a bit more? Does it need a change in the spin code?
I'm using a large (100k) text file.
Xmodem from the PC to drive A works fine and I can then take that zicog drive image and copy it off the sd card and put it back into the Altair SIMH and it is all there.
I can also do a TYPE on that large file and it all comes through.
PIP to another drive fails as we have found. I was thinking it was the 'write' but that would not explain why programs like wordstar that simply read large files then fail. Now I think it is the 'read' because I've just had it crash half way through a DUMP of the same large text file. So now I need to create a text file with numerical labels so I can see exactly which byte it fails on...
I've added this little bit of trace code to PRI refresh_hd_cache | r
Hi Guys, I'm back, with a vengeance. My Blade 2 is running at, wait for it, 104.857 6 MHz !!
Yep a 6.5536MHx XTAL and 16 times PLL. Cluso, hit the gas[noparse]:)[/noparse]
OK. Sorry, as you see I have been busy collecting TriBlade parts and assembling it. The state of the art here is:
Power supply. Only has 3.3v reg, the 5v reg is bypassed and the whole thing driven from 4 rechargeable AA batteries.
The LED's work [noparse]:)[/noparse]
Blade 2. Has Prop and EEPROM, latch and XTAL. Fitted the 10uF Tantalum and a 100nF ceramic to the back side. The ceramic is the only thing of the correct value that fits the holes that I could find around here quickly. Is it OK Cluso? What is an X7R anyway?
Question: Will this 104MHz speed be too much for the external RAM?
TODO:
The delicate RAM chopping and fitting.
Lash an SD card to it.
I don't have the SD card socket so somehow I have to hang it off the board with a ribbon cable as I did for my demo board.
A cunning plan: Now that I have a Blade running I'm prepared to read the last rights to my home made demo board. That board has a strong resemblance to the Flying Spaghetti Monster and I'm surprised it has lasted so long.
What I want to do is recycle its body parts for Blade 1. I'm thinking I could install it's Prop there and (with no RAM) hang it's SD card of the same Prop pins as the usual Demo Board attachment. This way I have a Triblade 2 and Prop Demo Board configuration for ZiCog all on the TriBlade[noparse]:)[/noparse].
I've been following your pain with the crashy BIOS. Hopefully I can get onto that real soon now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
PIP >32K works on version 122 when compiled with #define FloppySupport. This boots a 64K version of the floppy A drive. Pip to I: works and the file is correctly copied because a text file of 40K was copied and TYPE used to display it. PIP works both ways, so the caching is working. :-)
This means that the problem must be·to do with the·64K CPM boot code version (hdisk).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have not checked the exact timing specs but don't worry for now. The ceramic should be fine. The X7R is a tighter tolerance under temperature variation.
I just put in a 6MHz xtal and I have not fitted any caps under the processor yet. I want to see where this becomes critical. Now I want to get to 120MHz like Sapeiha has had running for 6mths, but this will have to wait for the correct xtals.
Drac: Do you have a 6MHz xtal ? If not I'll post you one. Not sure if you noticed, but today I had potatohead's TV running 80x25 characters on my TV today at 96MHz (on the TriBlade #2 - SRAM deselcted due to potential bus conflict. (jumpered without soldering the 3 pins from SRAM U24 to the links beside the TV resistors on the pcb. Guess I should have taken a photo hey - done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
More experiments.
1)
For the moment I've uncommented
hdskWrite:
UART.str(string("hdsk write"))
Interesting that it writes when you change drives and on warm boots. I didn't know that.
2)
Just for the moment I have the 3 second delay on bootup. I had this commented out for a while, and about 1 in 10 bootups were not loading the hard drives. Maybe they are related, maybe not. I'll keep testing that, but perhaps there needs to be a delay for other reasons, eg the sd card needs to stabilise the power supply? I'll do more testing, but maybe a small delay is always needed there, and maybe a comment about that could find its way into the code?
3) It is cool watching the code reading - ie read in 512 bytes and store in a temp array and if already have a 128 byte sector then read from the buffer. Watching the reads, it mostly is reading contiguous sectors. When doing a dump, every 16k it seems to go back and read about 10 of the sectors it reads on bootup.
4) I think the fail on DUMP of the large text file was a one-off. It is DUMPing 100k text files and also 100k random byte files with no problems at the moment.
5) re faster speed, I'd really like to get it working first before overclocking. But down the track...
Comments
I have the latch fitted.
I didn't understand that the wire from pin 11 to pin 17 on the latch must not be fitted if the latch is present. I should have spotted that the holes on the photo don't have solder in them.
Re "the modification described in the errata item 5 (on thread page 6), MUST be done..." Could you give the date and time of the relevant post as I'm having trouble finding that one.
Cheers, James
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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 to summarise in Plain English:
1) Pin 24 of the ram chip is removed from the socket and goes to pin 37 of the propeller.
2) pin 22 of the ram chip *still* goes to pin 17 of the latch AND there is no link between pin 11 and pin 17 on the latch?
I'm off to the shed to test this out...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
Pin 24 on the ram chip removed from the socket and joined to pin 37 of the propeller chip.
Results of experiment:
1) It boots the same as before, ie still works fine.
2) It seems faster
3) The bug doing a PIP of files >32k is still there
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
BTW: the hardware mod was required.
Heater: Code attached.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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) : 9/20/2009 1:22:31 PM GMT
***TrapperBob***
I've bundled up a zip of my working directory.
1) Unzip to a new folder
2) copy all the .dsk files to the sd card
3) copy ziboot.com to the sd card
4) copy zicog__2.ptr to the sd card (?not needed but it failed when not there)
5) To edit the program, double click zicog_cpm_rc5.5b_rr120.spin and edit in the standard prop tool.
6) To download, shrink the prop tool. Keep the directory open. Double click BST.BAT
7) It should compile, find the prop, and download and run teraterm and boot up
8) To re-edit, close teraterm.
Comments:
1) I'm running at 38k baud. You can change teraterm to faster and you can change the .spin code to faster. Search 38_400
2) I'm running v120 but have the disks very slightly different for disk E and F I think. This package is complete though. Cluso is changing some of the disk images around
3) I've just dumped all the teraterm files into the working directory so they are all in one place.
4) I removed the 3 sec delay on startup. teraterm doesn't need it.
5) Each update from Cluso, I copy all the files to a new directory and change the BST.BAT file to reflect the new .spin file
6) I have a copy of the altair simh if you want that.
7) This still has the bug copying big files. Maybe you can help out on that one??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/20/2009 1:49:51 PM GMT
So - I used teraterm to download xmodemf.com using the propeller version xmodemp.com.
Now one can send all the wordstar package, or the sbasic package in one go. So easy!
Better still, one can use the IDE for sbasic or BDSC or Assembly, with the copy and paste function and the coloured code etc.
And, it compiles on the board. And it is FAST!!! This is a screen capture of the program running on the triblade. Ok, I cheated a little and wrote the actual program on the PC using the N8VEM IDE (though I could have written it using notepad, or even wordstar [noparse][[/noparse]very soon once that bug is squisheed] on the triblade).
A>type new.bas comment call small procedures first then bigger procedures as can't call/reference a later procedure (one pass compiler) Dim common variables eg arrays at beginning of program end rem *** functions and procedures *** rem ************ MAIN ************** print "Hello World" end A> A>sbasic new tm S-BASIC Compiler Version 5.4b .0001:00 comment 0002:01 call small procedures first then bigger procedures 0003:01 as can't call/reference a later procedure (one pass compiler) 0004:01 Dim common variables eg arrays at beginning of program 0005:01 end 0006:00 rem *** functions and procedures *** 0007:00 0008:00 rem ************ MAIN ************** 0009:00 0010:00 print "Hello World" 0011:00 end 0012:00 ****** End of program ****** ...........................Compilation complete A>new Hello World A>▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Are you and Dr_A now in agreement that there is a bug with copying big files?
I have yet to see it on the Demo Board. Perhaps an external RAM access issue, perhaps something in the BIOS that shows up when built for 64K. Mysterious.
I think it might be wise to get rid of all those strange disk image file names in zicog_cpm.spin and just settle on something simple like "zicog_a.dsk, zicog_b.dsk" etc. People can always copy what ever images they have to those names on the SD card. These are really names for the virtual drive hardware rather than actual floppies (or HDs)
Are you desirous of having the floppy drive hardware support back in permanently? It makes an awful mess.
Still trying to construct a TriBlade here, but even on a Sunday real work gets in the way[noparse]:([/noparse]
Hope to pick up some more parts tomorrow though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks for the archive. I will give it a try later on today. I will try and look at the "big" file transfer problem.
Thanks
·
Well actually we (that is "you" just now) should experiment with PIPing big files around on the 25K build of CP/M on the TriBlade using HUB memory.
Then the same PIPing use the same 25K CP/M boot disk but using external memory.
If 25K in HUB works but 25K in ext fails then we have isolated the problem to the external RAM interface.
If they both work then it starts to look like problem in the BIOS when built for 64K.
Surely this experiment will give us a clue one way or another.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1) 25K works correctly on TriBlade with 64KB sram (both Z80 & 8080) & ZIPM2_64.DSK
I need to recheck your latest build of 64KB version (not sure if I have the latest).
re Floppy drives. Please leave code there until we are ready for the v1.0 release. It is useful to create hdrives from floppies.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
Drac: Could you repost a SD drive file with wordstar on it please.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
A quick question - are altair simh hard drives compatible with zicog drives?
If yes, then TYPE on a text file should work. But it doesn't. Try TYPE WSPRINT.TST and it should print some text (works on the simh) but it types rubbish characters and eventually crashes.
There are two ways to make a hard drive file on the zicog.
1) Copy an altair simh hard drive file (? does this work)
2) PIP *.* from a floppy drive image. (not working on all files due to the 'big file' bug)
So - 1) doesn't seem to work so I tried 2) and is how I found the big file bug in the first place. So - making a wordstar hard drive image is not possible right now!
Maybe there is an incompatability issue between altair and zicog hard drive images and since they seem so close (DIR partially works for instance), it would be worth working out a way. So I'm posting this file and maybe someone can replicate this problem.
Addit: Something is definitely wrong with the drive image. LS displays all the files but DIR leaves about half out:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/21/2009 8:09:15 AM GMT
PIP of files >28K (probably 32K) fails. I have seen other failures which are possibly due to the same bug, whatever it is. When I pip a 40K file it recovers after the garbage which is fairly consistent, but the file copied is corrupted.
I thought it may have been a conflict with the sram on triblade, but all the calls out of ZiCog Pasm to the upper spin code seem to have the correct bus release statements. The 25K version of CPM2.2 does pip correctly.
Drac, Do you remember I spoke of an additional chip... Well, I have just found a way in software to achieve the same speed increase without it :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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) : 9/21/2009 8:22:23 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Take a blank drive image on the simh and then on the zicog and PIP a single file from drive A.
Two screenshots of the two files side by side in a hex editor. Zicog at the top. SIMH at the bottom.
First difference is in the FCB with a byte 04 vs 08. This is the first byte of the disk allocation map so maybe there is something different in the disk parameters?
Second difference is the location of the data - at 8000 vs E000, which probably reflects the different disk allocation map.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/21/2009 9:15:18 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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
Is heater around? There are so many programs not working on the hard drives (that were working before) and I think we need his expert opinion about where to begin. I was thinking about taking drive images with lots of files and comparing the binaries with the simh, but got stuck on the first file. So next plan is to start putting UART.str comments through the spin code and try to track it down that way. Back to coding...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
It seems to be just the 64K build causing problems.
Drac: Will the programs that fail run in 25K. If so, can you compile this version (uses ZIPM2.DSK - see the FindDriveBase section) and try the programs ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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) : 9/22/2009 10:33:27 AM GMT
I'm using a large (100k) text file.
Xmodem from the PC to drive A works fine and I can then take that zicog drive image and copy it off the sd card and put it back into the Altair SIMH and it is all there.
I can also do a TYPE on that large file and it all comes through.
PIP to another drive fails as we have found. I was thinking it was the 'write' but that would not explain why programs like wordstar that simply read large files then fail. Now I think it is the 'read' because I've just had it crash half way through a DUMP of the same large text file. So now I need to create a text file with numerical labels so I can see exactly which byte it fails on...
I've added this little bit of trace code to PRI refresh_hd_cache | r
uart.dec(sd_block_number) uart.str(string(":")) uart.dec(current_block_number) uart.str(string(", "))▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Yep a 6.5536MHx XTAL and 16 times PLL. Cluso, hit the gas[noparse]:)[/noparse]
OK. Sorry, as you see I have been busy collecting TriBlade parts and assembling it. The state of the art here is:
Power supply. Only has 3.3v reg, the 5v reg is bypassed and the whole thing driven from 4 rechargeable AA batteries.
The LED's work [noparse]:)[/noparse]
Blade 2. Has Prop and EEPROM, latch and XTAL. Fitted the 10uF Tantalum and a 100nF ceramic to the back side. The ceramic is the only thing of the correct value that fits the holes that I could find around here quickly. Is it OK Cluso? What is an X7R anyway?
Question: Will this 104MHz speed be too much for the external RAM?
TODO:
The delicate RAM chopping and fitting.
Lash an SD card to it.
I don't have the SD card socket so somehow I have to hang it off the board with a ribbon cable as I did for my demo board.
A cunning plan: Now that I have a Blade running I'm prepared to read the last rights to my home made demo board. That board has a strong resemblance to the Flying Spaghetti Monster and I'm surprised it has lasted so long.
What I want to do is recycle its body parts for Blade 1. I'm thinking I could install it's Prop there and (with no RAM) hang it's SD card of the same Prop pins as the usual Demo Board attachment. This way I have a Triblade 2 and Prop Demo Board configuration for ZiCog all on the TriBlade[noparse]:)[/noparse].
I've been following your pain with the crashy BIOS. Hopefully I can get onto that real soon now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
PIP >32K works on version 122 when compiled with #define FloppySupport. This boots a 64K version of the floppy A drive. Pip to I: works and the file is correctly copied because a text file of 40K was copied and TYPE used to display it. PIP works both ways, so the caching is working. :-)
This means that the problem must be·to do with the·64K CPM boot code version (hdisk).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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) : 9/22/2009 11:06:36 AM GMT
I have not checked the exact timing specs but don't worry for now. The ceramic should be fine. The X7R is a tighter tolerance under temperature variation.
I just put in a 6MHz xtal and I have not fitted any caps under the processor yet. I want to see where this becomes critical. Now I want to get to 120MHz like Sapeiha has had running for 6mths, but this will have to wait for the correct xtals.
Drac: Do you have a 6MHz xtal ? If not I'll post you one. Not sure if you noticed, but today I had potatohead's TV running 80x25 characters on my TV today at 96MHz (on the TriBlade #2 - SRAM deselcted due to potential bus conflict. (jumpered without soldering the 3 pins from SRAM U24 to the links beside the TV resistors on the pcb. Guess I should have taken a photo hey - done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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) : 9/22/2009 11:34:47 AM GMT
1)
For the moment I've uncommented
hdskWrite: UART.str(string("hdsk write"))Interesting that it writes when you change drives and on warm boots. I didn't know that.
2)
Just for the moment I have the 3 second delay on bootup. I had this commented out for a while, and about 1 in 10 bootups were not loading the hard drives. Maybe they are related, maybe not. I'll keep testing that, but perhaps there needs to be a delay for other reasons, eg the sd card needs to stabilise the power supply? I'll do more testing, but maybe a small delay is always needed there, and maybe a comment about that could find its way into the code?
3) It is cool watching the code reading - ie read in 512 bytes and store in a temp array and if already have a 128 byte sector then read from the buffer. Watching the reads, it mostly is reading contiguous sectors. When doing a dump, every 16k it seems to go back and read about 10 of the sectors it reads on bootup.
4) I think the fail on DUMP of the large text file was a one-off. It is DUMPing 100k text files and also 100k random byte files with no problems at the moment.
5) re faster speed, I'd really like to get it working first before overclocking. But down the track...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·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