I have the RamDisk working as floppy drive F: It is just blank, so anything required had to be PIP'ed across. Now, want to make it a hard drive since that is much faster. Do you have hdp parameters for a floppy (although I will have to shrink it slightly or a lot depending on if I have 512KB or 1MB) ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
In zicog_demo.spin the "hard drive" drive L: is defined as a 720K floppy as follows:
dpb_3 '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.
You might want to play with setting off_low and off_high to zero as we don't want boot sectors on a floppy.
Then perhaps dsm_low, dsm_high to limit the size.
All those other params are related in complicated ways, best read the CP/M manual first if you want to mess with them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have just played with the max data blocks $006F = 444KB (from hdp_1)
All works fine except PIP does not seem to check the boundaries and copies all the files from the A:*.* without problems and a DIR shows them all present but of course they cannot be (no room for al of them).
So I have RamDisk working as both a floppy and a hard drive, but 444KB which is 512-64KB=448KB. I noticed that the drives seem to be 1 block less for some reason, so I did this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Not sure where all this is leading but I have created a new CBIOSX that has only 2 Altair floppies (A: and B[noparse]:)[/noparse] and 1 hard drive (C[noparse]:)[/noparse]
Sounds like MSDOS does it not?
ZiCog v0.10 on the Prop Demo Board
Starting disks (A:B:C:) ...
Passed, please wait...
RAM base = 00E8
ROM base = 58E8
Starting Z80 emulation...
Passed, please wait...
24K CP/M Version 2.2 (ZiCog, BIOS V1.27_Z01, 1 HD, 29-Aug-2009)
A>c:ls a:
0 File(s), occupying 0K of 984K total capacity
256 directory entries and 984K bytes remain on A:
A>c:ls b:
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
LS COM 2K
1 File(s), occupying 2K of 984K total capacity
255 directory entries and 982K bytes remain on B:
A>c:ls c:
Name Ext Bytes Name Ext Bytes Name Ext Bytes Name Ext Bytes
LS COM 4K
1 File(s), occupying 4K of 8136K total capacity
255 directory entries and 7996K bytes remain on C:
A>
A floppy with this CBIOS still boots on SIMH and at least proves the point that we can easily hack the CBIOS how we like.
Continuing on this path we could define 1 Altair floppy driver, or none, and many HDs of whatever geometry we like, floppy, HD, RAM disk etc.
Next up I going to put some floppy disk geometries in our HD emulation.
If we can get HDSKBOOT working then we could dispense with the floppy driver emulation altogether. That's a bit of a problem on the DemoBoard as HDSKBOOT requires 24K RAM.
If you are OK with only 1 or two floppy drivers and the rest using the HD driver I will put that into the next release and post the CBIOS and build system to go with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater said...
Next up I going to put some floppy disk geometries in our HD emulation.
If we can get HDSKBOOT working then we could dispense with the floppy driver emulation altogether. That's a bit of a problem on the DemoBoard as HDSKBOOT requires 24K RAM.
If you are OK with only 1 or two floppy drivers and the rest using the HD driver I will put that into the next release and post the CBIOS and build system to go with it.
Does a hard disk take up any more space in the BIOS than a floppy??? (e.g we have 8 floppies + 2 HD. Does this = 2 floppies + 8 HD in CPM space?)
Yes... Once we have HDSKBOOT working I see no reason that we can't have only hard drives, at least 2 of which could be defined as floppy geometries (CPM2 & CPM3). Then we can boot from either. Then a couple of 8MB drives, 1 smaller drive for RamDisk, and 1 big drive. So I see 6-8 hard drives and no actual floppies. Does this make sense???
For the DemoBoard, maybe a reduced CBIOS with only 2 hard drives, 1 being a floppy size and another 8MB hard disk. That may free up enough space for your 24KB RAM. Maybe packing is taking valuable code space???
I see no problem with a small converter program (VB6 or Python or whatever) to convert the SIMH Floppy format to SD format (137 -> 128 and packed or not). Remember, SD space is plenty and much faster than the old hard drives, so the speed gain of packing is not really necessary.
I have the RamDisk working as either a floppy or hard drive. It would be easy to force the writes out to the SD card copy also, so a huge gain could be had here, with the caveat that it is a small drive.
I have an issue with the hdp_1 (my RamDisk). I made the max data blocks parameter smaller, but CPM is not seeing this and STAT still reports the drive as 8MB. Is the CBIOS only using hdp_0 for both HD ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ultra busy this weekend with work so not able to contribute much, sorry. Some exciting developments with the clusos ram drive (looking forward to testing that) and heater "If you are OK with only 1 or two floppy drivers and the rest using the HD driver I will put that into the next release and post the CBIOS and build system to go with it." The cbios and build system sounds great. Is it able to boot from a hard drive, ie load up all the settings etc from the hard drive boot tracks rather than from the drive__1m.dsk? I tried to decode how the data is stored with the alternate sectors etc but it is very complicated. Things are moving so fast I'm getting left behind. Only 5 more hours to go at work...
In theory using the hard disk driver for floppies should take the same space as the floppy driver if the disk geometries are the same. Hard disks will take more space depending on their size and space reserved fro directory entries I believe. I'll try and verify this.
I just woke up with a great idea. Currently if we do hard disk boot like SIMH it puts HDSKBOOT.COM at 5C00 and the reads boot sectors from disk filling memory from 0 to 5BFF. Hence the need for at least 24K RAM.
The idea is: Why not just put the HDSKBOOT code in our ROM space at FF00 and run it from there same as DSKBOOT. Its just a small change to HDSKBOOT.MAC
Also DISKBOOT copies it self from FF00 to 5C00 and the executes from there. RAM was faster than ROM. Why don't we just change it to run in place from our ROM space.
I'm going to change the BIOS floppy driver to 128 byte sectors. Even if we end up not using it.
I'll check that hdp_ 1 issue.
At the end of the day we may have moved far away from Altair compatibility. What with no floppy driver, no 137 byte sectors, no disk sector skewing, hdskboot in ROM etc.
This breaks one of my original and high priority requirements and I'm a bit sad about moving away from the Altair.
But its time to let some pragmatism take over. we never did have true Altair compatibility anyway, i.e. just drop a Altair CP/M 2 disk image in and run without pre processing it. For us to support the Altair hardware style driver in Spin is slow and clumsy perhaps it's time to put it out of it's misery [noparse]:)[/noparse]
As long as we can build our boot disks on SIMH and as long as exporting all those SIMH disk images to ZiCog is easy then we should go for a floppy drive free ZiCog. Also means we can shrink the BIOS by removing the floppy code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: Sounds good to me. You achieved the original goal anyway. Now it the time to go beyond that, and it will be so much better.
If is as simple as loading HDSKBOOT.MAC into FF00 and executing it, then why not load it as an SD file by that name (like I am now doing for DSKBOOT.COM)?
And yes, no floppies so we can shrink the BIOS - no need for it when it is on 1 SD card anyway. Maybe 8 Hard Drives??? Would allow us to map some old floppies as hard drives, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Having said all that there is still the BIOSs of CP/M 3 and MP/M to worry about. They would need similar mods to run on ZiCog. Should be manageable as the changes are in fact not huge. Still we should not totally throw out the Altair floppy driver code so fast. Sounds like some more #ifdefs [noparse]:)[/noparse]
IMPORTANT: We still need to rename zicog_demo. I had thought "zicog_altair" but that is now fading away.
Any suggestions ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here is the latest ZiCog / TriBlade code. You will also require the·other drive files on your Sd card - they are posted at the top of this thread.
This code compiles with bst. It has a RamDisk of 444KB and is mapped as Drive J: which is a hard disk. Unzip DRIVE_E5.DSK and copy it to HDRIVE_I.DSK·on the SD card.·This way you can just pip files to it as an 8MB hard drive I: You will also need to copy DSKBOOT_.ROM on the SD card. WARNING: The RamDisk size is not being limited in size by CPM like it should - it is being missreported as an 8MB drive.
To test the ramdisk, do
A>DIR J:
A>PIP J:=MBASIC.COM
A>DIR J:
To copy to the I: drive, do
A>PIP I:=*.*
A>DIR I:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ok, minor change to above description - copy the drive DRIVE_E5.DSK to both HDRIVE_I.DSK and HDRIVE_J.DSK
The hard drives are great. But... check out drive J which is the ramdrive. Loads MBASIC in about 1/2 of a second!!!!
That is the N8VEM's speed. Which makes sense in a way as the N8VEM is using the same ram chip.
So - loading MBASIC is 12 seconds for the floppy drive emulation, 4 seconds with the hard drive emulation and now way under a second. Fantastic work and kudos to all!
Re toby
Cluso and Heater
Sorry to be ignorant but if I were to start with this project at this point :-
I assume that bst with its conditionals is a must
Are you using Blade1 and 512Kb, Blade2 with 512Kb or 1Mb etc
I have a "Blade2" 1Mb made but have lost track of this thread (and never get the peace to read the back threads properly)
I'm using a little .bat file called bst.bat with two lines in it
bstc -e -Ox zicog010_demo_rr107.spin
pause
I'm wondering if cluso might include the little .bat file and also include bst itself with each package? Only adds a tiny amount to each package but then each release becomes self contained.
This is working on a very stripped down triblade. Nothing on blade 1 at all. 1 ram chip on blade 2. But cluso has two ram chips on blade 2, so I think we can say it works with either. Though it might not report a 'drive full' properly yet.
Post Edited (Dr_Acula) : 8/30/2009 12:06:13 PM GMT
In order to support a variety of memory sizes / platforms conditional compilation is almost a must.
We are still on 1M byte. I say "we" but I still have not built my TriBlade.
Not surprised you have lost track of this thread it's a shambles and everything is in a constant state of flux.
I'm hoping to soon come to a point of stability with Version 1.0 of a TriBlade running CP/M.
At the point we will have a new name for it (not decided yet) and start a new thread where its future versions can be followed more easily.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Toby, I was going to post a zipped up package that contains everything but I have a very fickle sd card reader and it only works when the moon is in the right quadrant. Essentially you need the packages cluso posted, plus the bst.com program, plus a bst.bat you can make out of the two lines above.
Next best thing - see attached zip. Clone the drive A to drive B to H. Clone drive drive e5 to hdrive_i and hdrive_j. If anything is not on the sd card, you get an error message (which is a really cool thing about this emulation as you get a really useful clue about where it failed)
And just note my version is 38400 baud not 115k and also skips the 3 sec delay at startup. But otherwise the same as cluso's just a few posts above.
We probably should try to package up versions with everything included. The huge drive images seem to zip down to hardly anything - a 32mb file filled with E5 seems to zip to 32k.
Building is a 3 step process:
Run BST.bat
Double click the resulting .eeprom and it should open the prop tool and download it
Open a terminal program (eg teraterm) (which also reboots the triblade)
Building is a 3 step process:
Run BST.bat
Double click the resulting .eeprom and it should open the prop tool and download it
Open a terminal program (eg teraterm) (which also reboots the triblade)
If you were to use bstc to load the propeller after compiling you'd save another step (and it loads faster than the propeller tool).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Hi Brad, that sounds great. Would you be able to post the syntax by any chance?
it is something to do with this I think:
-o <filename> - Output [noparse][[/noparse].list/.eeprom/.binary/.zip] Filename (Defaults to input Filename without .spin)
I don't think I am doing it right though. This is my batch file:
There is no need for a bat file as bst has an integrated editor, compiler including listing, downloader and terminal program, although the downloader and terminal program doesn't work for me on Vista - cannot find the prop serial (USB) port. bst can also zip up a package of source files.
So here is how I compile...
Open in this order...
* bst
* PropTool
* PropTerminal
Then do the following...
* PropTerminal - under options, click on CR with Auto LF. Do this twice as there is a bug, first time places a tick, second removes it - you need to do this each time you open PropTerm (not reclcking on it). Now minimise PropTerm - this is how it releases the port for downloading.
Now to edit/compile/load/test do (and repeat) the following....
* bst - click on bst and start a new project called ZiCog_demo_rr107. Then load the file ZiCog_demo_rr107.spin. Now compile the program and save the binary. A listing is available - a little trick, open the listing window before you compile, then reopen the listing window after the compile and you will see the listing.
* PropTool - click on PropTool and open the binary and download it to the prop ram. As soon as it loads quickly...
* ProTerm - click on PropTerm. In about 3 seconds it will start showing the ZiCog loading. I use 115,200 baud without problems. IIRC it takes about 20 seconds to get to the A> prompt. When done, don't forget to minimise or you will not be able to download the code (cannot find the serial port).
Now for my hardware. I am using a new TriBlade. I have built the power supply, the propplug section and just Blade #2 with only 1 512KB SRAM in U23. There are instructions for this to get the pcb completed to this point at the beginning of this thread. Do not forget the OE modification. Now to get it all to work, just connect 3 (or 4) wires/cables from J21 to J92 (G is not required as it is already connected). You can use 4 pin headers and a cable for this. I have some RS232 male to male pins that I use for jumpers. Later, you may need to use the PropPlug section as standalone, so I suggest you do not solder wires here. You can solder both 512KB SRAMs in U23 & U24 but ensure you do the OE mod to both SRAMs.
If you have any questions, please ask.
I expect over the next few days we will get to a full release and then I will re-release everything.
@Brad: May I suggest a link to your website and thread for bst in your signature??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Dr_Acula, since bstc works for you, can you see it the Terminal program in bst works. Then you will have a complete ide - editor, compiler, listing, downloader and terminal program, all-in-one. Then there is no need for a batch file or command line processor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I was saying to a work mate, last Thursday, that I regretted becoming lazy with Windoze click this, click that, and really should get back to command line stuff. He then made it worse by saying he has gone completely Windozeless and is becoming all powerful on server versions. Just like the old days, learnt something only to forgetit and then yearn for it back. Bit like the Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
1) I'd like to merge the 4 sectors per SD block code into zicog_demo. However Cluso has reservations about that so perhaps not just now.
2) I'd like to take up Cluso's suggestion of forking this project into two versions:
a) A version that works with HUB memory only, no external RAM. Possibly with all the #ifdefs stripped out so that it can be built by anyone with a Parallax Propeller tool easily. It would keep Altair compatibility and be renamed "ZiCogAltair" or such. It may have all HD support removed. This version would probably not see much future development. It would use bog standard CP/M from SIMH.
b) A version for ZiCog on platforms with external memory, TriBlade, RamBlade, Morpheus etc. Call it ZiCogXram or something like. Cluso's suggestion. Pretty much carrying on development as we are doing.
Both these versions would get a new thread on the forum.
3) I'd like to continue ZiCogXram (or whatever we decide to call it) by:
a) Removing the floppy driver support from the CBIOS and from the emulation.
b) Getting our current floppy image geometries into the HD driver tables so that we can support SIMH floppies with minimal sector massaging with the HD driver.
c) Getting HDSKBOOT.COM to work from FF00 like the DSKBOOT.
Consider that these BIOS changes will also have to be done for CP/M 3 and MP/M.....
BUT we now have PropIO interoperability to think about. I'm sure the Altair style driver is out for that.
besides the Altair driver is slowwww.
Any suggestions? Definite Yes, yes's or No, no's ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cluso - yes I'll have a look at the bst terminal. I've been doing things that need VT100 terminal codes (eg wordstar) and also xmodem for file downloads. Teraterm, hyperterminal and my vb.net terminal program can both do VT100 and xmodem. Can the bst terminal do those as well?
Re heaters ponderings, the one thing I'd like to see is a bit more speed. For instance, when you are in a drive and you change to another drive, it takes a long time to change drives. Ditto when you are in mbasic or wordstar and return to the system. I think both processes involve a 'warm boot'. A warm boot involves reloading cp/m off the disk and the disks are the sd disks which are slow. I added a switch some months ago to the N8VEM where you could bypass reloading cp/m on a warm boot and it seems to work fine. There are a handful of programs that overwrite cp/m but not the ones I use so a reload of cp/m is not needed.
And as a general question, are the sd card reads now as fast as they can possibly be?
However, I just thought of a cunning plan. Now that cluso has very cleverly added drive J, the ramdrive, would it be possible on bootup to move the bootloader code over to drive J, say on the 'boot tracks' of the ram drive. Then subsequent warm boots would load off the ram drive and it would be much faster changing drives etc.
Or bypass the warm boot code? But that moves away from simh compatability. I know there is a circular argument regarding that, but one aim of any software ought to be to make it user friendly and if it becomes more hardware specific then it can be re-posted as a simh variant.
re a hub memory only version, how much hub ram is free now? I'm pondering crazy ideas like loading in an 8k block of data from the sram chip into hub memory as part of the zicog simulation, and then as the program jumps around it probably will be in that block of code and then you don't have to read the instructions from sram each time. ? would it give a speedup Is there enough hub ram free? Addit no, scratch that idea - it would work for a self contained program but not so good if the program called cp/m bdos calls a lot as these parts of code are at either ends of the 64k ram space.
So - back to reality...
Are we ready to move to CPM3 and MPM? A big project, but it would be really cool to see multitasking running.
Post Edited (Dr_Acula) : 8/31/2009 12:20:56 AM GMT
Count me for a yes
Count me NO for packed drives for now (postedit)
re the packed sectors (4x128 per 512 SD sector)...
Yoda & LynchAJ: How will you do the unpacking if we progress to packed sectors? My thoughts are
* it is simpler and easier to just waste space and use 1x128 per 512
* less wear on the SD card or we have to implement smarts which I think is harder on your N8VEM
* we want to keep the SD card files the same for TriBlade, Morpheus, PropIO and N8VEM
* any extra config files required for different hardware can be on the SD card
* all files(drive files) will be under FAT16 on the SD card, so cards up to 2GB
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
In zicog_demo.spin the "hard drive" drive L: is defined as a 720K floppy as follows:
dpb_3 '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.You might want to play with setting off_low and off_high to zero as we don't want boot sectors on a floppy.
Then perhaps dsm_low, dsm_high to limit the size.
All those other params are related in complicated ways, best read the CP/M manual first if you want to mess with them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
All works fine except PIP does not seem to check the boundaries and copies all the files from the A:*.* without problems and a DIR shows them all present but of course they cannot be (no room for al of them).
So I have RamDisk working as both a floppy and a hard drive, but 444KB which is 512-64KB=448KB. I noticed that the drives seem to be 1 block less for some reason, so I did 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
Sounds like MSDOS does it not?
A floppy with this CBIOS still boots on SIMH and at least proves the point that we can easily hack the CBIOS how we like.
Continuing on this path we could define 1 Altair floppy driver, or none, and many HDs of whatever geometry we like, floppy, HD, RAM disk etc.
Next up I going to put some floppy disk geometries in our HD emulation.
If we can get HDSKBOOT working then we could dispense with the floppy driver emulation altogether. That's a bit of a problem on the DemoBoard as HDSKBOOT requires 24K RAM.
If you are OK with only 1 or two floppy drivers and the rest using the HD driver I will put that into the next release and post the CBIOS and build system to go with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes... Once we have HDSKBOOT working I see no reason that we can't have only hard drives, at least 2 of which could be defined as floppy geometries (CPM2 & CPM3). Then we can boot from either. Then a couple of 8MB drives, 1 smaller drive for RamDisk, and 1 big drive. So I see 6-8 hard drives and no actual floppies. Does this make sense???
For the DemoBoard, maybe a reduced CBIOS with only 2 hard drives, 1 being a floppy size and another 8MB hard disk. That may free up enough space for your 24KB RAM. Maybe packing is taking valuable code space???
I see no problem with a small converter program (VB6 or Python or whatever) to convert the SIMH Floppy format to SD format (137 -> 128 and packed or not). Remember, SD space is plenty and much faster than the old hard drives, so the speed gain of packing is not really necessary.
I have the RamDisk working as either a floppy or hard drive. It would be easy to force the writes out to the SD card copy also, so a huge gain could be had here, with the caveat that it is a small drive.
I have an issue with the hdp_1 (my RamDisk). I made the max data blocks parameter smaller, but CPM is not seeing this and STAT still reports the drive as 8MB. Is the CBIOS only using hdp_0 for both HD ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 (Dr_Acula) : 8/30/2009 4:34:01 AM GMT
I just woke up with a great idea. Currently if we do hard disk boot like SIMH it puts HDSKBOOT.COM at 5C00 and the reads boot sectors from disk filling memory from 0 to 5BFF. Hence the need for at least 24K RAM.
The idea is: Why not just put the HDSKBOOT code in our ROM space at FF00 and run it from there same as DSKBOOT. Its just a small change to HDSKBOOT.MAC
Also DISKBOOT copies it self from FF00 to 5C00 and the executes from there. RAM was faster than ROM. Why don't we just change it to run in place from our ROM space.
I'm going to change the BIOS floppy driver to 128 byte sectors. Even if we end up not using it.
I'll check that hdp_ 1 issue.
At the end of the day we may have moved far away from Altair compatibility. What with no floppy driver, no 137 byte sectors, no disk sector skewing, hdskboot in ROM etc.
This breaks one of my original and high priority requirements and I'm a bit sad about moving away from the Altair.
But its time to let some pragmatism take over. we never did have true Altair compatibility anyway, i.e. just drop a Altair CP/M 2 disk image in and run without pre processing it. For us to support the Altair hardware style driver in Spin is slow and clumsy perhaps it's time to put it out of it's misery [noparse]:)[/noparse]
As long as we can build our boot disks on SIMH and as long as exporting all those SIMH disk images to ZiCog is easy then we should go for a floppy drive free ZiCog. Also means we can shrink the BIOS by removing the floppy code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If is as simple as loading HDSKBOOT.MAC into FF00 and executing it, then why not load it as an SD file by that name (like I am now doing for DSKBOOT.COM)?
And yes, no floppies so we can shrink the BIOS - no need for it when it is on 1 SD card anyway. Maybe 8 Hard Drives??? Would allow us to map some old floppies as hard drives, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
IMPORTANT: We still need to rename zicog_demo. I had thought "zicog_altair" but that is now fading away.
Any suggestions ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Pulling HDSKBOOT and DSKBOOT from an SD card file to FF00 is a great idea.
OK no floppy disk driver, a shrunken BIOS, and many hard drives is next on my list of experiments.
Well, first I have to prove we can put the floppy geometry into the HDS driver table successfully.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This code compiles with bst. It has a RamDisk of 444KB and is mapped as Drive J: which is a hard disk. Unzip DRIVE_E5.DSK and copy it to HDRIVE_I.DSK·on the SD card.·This way you can just pip files to it as an 8MB hard drive I: You will also need to copy DSKBOOT_.ROM on the SD card. WARNING: The RamDisk size is not being limited in size by CPM like it should - it is being missreported as an 8MB drive.
To test the ramdisk, do
A>DIR J:
A>PIP J:=MBASIC.COM
A>DIR J:
To copy to the I: drive, do
A>PIP I:=*.*
A>DIR I:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/30/2009 11:43:19 AM GMT
Sorry to be ignorant but if I were to start with this project at this point :-
I assume that bst with its conditionals is a must
Are you using Blade1 and 512Kb, Blade2 with 512Kb or 1Mb etc
I have a "Blade2" 1Mb made but have lost track of this thread (and never get the peace to read the back threads properly)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
Ok, minor change to above description - copy the drive DRIVE_E5.DSK to both HDRIVE_I.DSK and HDRIVE_J.DSK
The hard drives are great. But... check out drive J which is the ramdrive. Loads MBASIC in about 1/2 of a second!!!!
That is the N8VEM's speed. Which makes sense in a way as the N8VEM is using the same ram chip.
So - loading MBASIC is 12 seconds for the floppy drive emulation, 4 seconds with the hard drive emulation and now way under a second. Fantastic work and kudos to all!
Re toby
Cluso and Heater
Sorry to be ignorant but if I were to start with this project at this point :-
I assume that bst with its conditionals is a must
Are you using Blade1 and 512Kb, Blade2 with 512Kb or 1Mb etc
I have a "Blade2" 1Mb made but have lost track of this thread (and never get the peace to read the back threads properly)
I'm using a little .bat file called bst.bat with two lines in it
bstc -e -Ox zicog010_demo_rr107.spin
pause
I'm wondering if cluso might include the little .bat file and also include bst itself with each package? Only adds a tiny amount to each package but then each release becomes self contained.
This is working on a very stripped down triblade. Nothing on blade 1 at all. 1 ram chip on blade 2. But cluso has two ram chips on blade 2, so I think we can say it works with either. Though it might not report a 'drive full' properly yet.
Post Edited (Dr_Acula) : 8/30/2009 12:06:13 PM GMT
We are still on 1M byte. I say "we" but I still have not built my TriBlade.
Not surprised you have lost track of this thread it's a shambles and everything is in a constant state of flux.
I'm hoping to soon come to a point of stability with Version 1.0 of a TriBlade running CP/M.
At the point we will have a new name for it (not decided yet) and start a new thread where its future versions can be followed more easily.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Next best thing - see attached zip. Clone the drive A to drive B to H. Clone drive drive e5 to hdrive_i and hdrive_j. If anything is not on the sd card, you get an error message (which is a really cool thing about this emulation as you get a really useful clue about where it failed)
And just note my version is 38400 baud not 115k and also skips the 3 sec delay at startup. But otherwise the same as cluso's just a few posts above.
We probably should try to package up versions with everything included. The huge drive images seem to zip down to hardly anything - a 32mb file filled with E5 seems to zip to 32k.
Building is a 3 step process:
Run BST.bat
Double click the resulting .eeprom and it should open the prop tool and download it
Open a terminal program (eg teraterm) (which also reboots the triblade)
hp.vector.co.jp/authors/VA002416/teraterm.html and get the March 10 1998 version (which works fine on xp).
More input from others would be great!
Post Edited (Dr_Acula) : 8/30/2009 12:42:36 PM GMT
If you were to use bstc to load the propeller after compiling you'd save another step (and it loads faster than the propeller tool).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
it is something to do with this I think:
-o <filename> - Output [noparse][[/noparse].list/.eeprom/.binary/.zip] Filename (Defaults to input Filename without .spin)
I don't think I am doing it right though. This is my batch file:
bstc -e -Ox zicog010_demo_rr107.spin
bstc -o zicog010_demo_rr107.eeprom
pause
addit - trying some other things -d and -p but I don't know the syntax for those, eg is it -d:com1, and is it -p
addit addit - right brackets and left brackets get modified by this forum so -p right square bracket 2 left square bracket
Post Edited (Dr_Acula) : 8/30/2009 1:46:17 PM GMT
just use
bstc -p0 -d COM1 -Ox zicog010_demo_rr107.spin
and skip the .eeprom file completely. (or -p2 if you want to load the eeprom instead of ram)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
bstc -p2 -d COM1 -e -Ox zicog010_demo_rr107.spin
pause
No need to have the eeprom file on the pc really. Just compile and send. Thanks++.
C:\Propeller\zicog92\Cluso 30 8 09>bstc -p2 -d COM1 -e -Ox zicog010_demo_rr107.s
pin
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Win32 at 08:17:48 on 2009/07/20
Loading Object zicog010_demo_rr107
Loading Object zicog
Loading Object FullDuplexSerial_rr004
Loading Object TriBladeProp_Blade2_202
Loading Object fsrwFemto
Loading Object sdspiFemto
Program size is 17180 longs
Compiled 4018 Lines of Code in 0.437 Seconds
We found a Propeller Version 1
Propeller Load took 8.14 Seconds
C:\Propeller\zicog92\Cluso 30 8 09>pause
Press any key to continue . . .
There is no need for a bat file as bst has an integrated editor, compiler including listing, downloader and terminal program, although the downloader and terminal program doesn't work for me on Vista - cannot find the prop serial (USB) port. bst can also zip up a package of source files.
So here is how I compile...
Open in this order...
* bst
* PropTool
* PropTerminal
Then do the following...
* PropTerminal - under options, click on CR with Auto LF. Do this twice as there is a bug, first time places a tick, second removes it - you need to do this each time you open PropTerm (not reclcking on it). Now minimise PropTerm - this is how it releases the port for downloading.
Now to edit/compile/load/test do (and repeat) the following....
* bst - click on bst and start a new project called ZiCog_demo_rr107. Then load the file ZiCog_demo_rr107.spin. Now compile the program and save the binary. A listing is available - a little trick, open the listing window before you compile, then reopen the listing window after the compile and you will see the listing.
* PropTool - click on PropTool and open the binary and download it to the prop ram. As soon as it loads quickly...
* ProTerm - click on PropTerm. In about 3 seconds it will start showing the ZiCog loading. I use 115,200 baud without problems. IIRC it takes about 20 seconds to get to the A> prompt. When done, don't forget to minimise or you will not be able to download the code (cannot find the serial port).
Now for my hardware. I am using a new TriBlade. I have built the power supply, the propplug section and just Blade #2 with only 1 512KB SRAM in U23. There are instructions for this to get the pcb completed to this point at the beginning of this thread. Do not forget the OE modification. Now to get it all to work, just connect 3 (or 4) wires/cables from J21 to J92 (G is not required as it is already connected). You can use 4 pin headers and a cable for this. I have some RS232 male to male pins that I use for jumpers. Later, you may need to use the PropPlug section as standalone, so I suggest you do not solder wires here. You can solder both 512KB SRAMs in U23 & U24 but ensure you do the OE mod to both SRAMs.
If you have any questions, please ask.
I expect over the next few days we will get to a full release and then I will re-release everything.
@Brad: May I suggest a link to your website and thread for bst in your 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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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'll have a crack at all that.
I was saying to a work mate, last Thursday, that I regretted becoming lazy with Windoze click this, click that, and really should get back to command line stuff. He then made it worse by saying he has gone completely Windozeless and is becoming all powerful on server versions. Just like the old days, learnt something only to forgetit and then yearn for it back. Bit like the Z80.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1) I'd like to merge the 4 sectors per SD block code into zicog_demo. However Cluso has reservations about that so perhaps not just now.
2) I'd like to take up Cluso's suggestion of forking this project into two versions:
a) A version that works with HUB memory only, no external RAM. Possibly with all the #ifdefs stripped out so that it can be built by anyone with a Parallax Propeller tool easily. It would keep Altair compatibility and be renamed "ZiCogAltair" or such. It may have all HD support removed. This version would probably not see much future development. It would use bog standard CP/M from SIMH.
b) A version for ZiCog on platforms with external memory, TriBlade, RamBlade, Morpheus etc. Call it ZiCogXram or something like. Cluso's suggestion. Pretty much carrying on development as we are doing.
Both these versions would get a new thread on the forum.
3) I'd like to continue ZiCogXram (or whatever we decide to call it) by:
a) Removing the floppy driver support from the CBIOS and from the emulation.
b) Getting our current floppy image geometries into the HD driver tables so that we can support SIMH floppies with minimal sector massaging with the HD driver.
c) Getting HDSKBOOT.COM to work from FF00 like the DSKBOOT.
Consider that these BIOS changes will also have to be done for CP/M 3 and MP/M.....
BUT we now have PropIO interoperability to think about. I'm sure the Altair style driver is out for that.
besides the Altair driver is slowwww.
Any suggestions? Definite Yes, yes's or No, no's ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re heaters ponderings, the one thing I'd like to see is a bit more speed. For instance, when you are in a drive and you change to another drive, it takes a long time to change drives. Ditto when you are in mbasic or wordstar and return to the system. I think both processes involve a 'warm boot'. A warm boot involves reloading cp/m off the disk and the disks are the sd disks which are slow. I added a switch some months ago to the N8VEM where you could bypass reloading cp/m on a warm boot and it seems to work fine. There are a handful of programs that overwrite cp/m but not the ones I use so a reload of cp/m is not needed.
And as a general question, are the sd card reads now as fast as they can possibly be?
However, I just thought of a cunning plan. Now that cluso has very cleverly added drive J, the ramdrive, would it be possible on bootup to move the bootloader code over to drive J, say on the 'boot tracks' of the ram drive. Then subsequent warm boots would load off the ram drive and it would be much faster changing drives etc.
Or bypass the warm boot code? But that moves away from simh compatability. I know there is a circular argument regarding that, but one aim of any software ought to be to make it user friendly and if it becomes more hardware specific then it can be re-posted as a simh variant.
re a hub memory only version, how much hub ram is free now? I'm pondering crazy ideas like loading in an 8k block of data from the sram chip into hub memory as part of the zicog simulation, and then as the program jumps around it probably will be in that block of code and then you don't have to read the instructions from sram each time. ? would it give a speedup Is there enough hub ram free? Addit no, scratch that idea - it would work for a self contained program but not so good if the program called cp/m bdos calls a lot as these parts of code are at either ends of the 64k ram space.
So - back to reality...
Are we ready to move to CPM3 and MPM? A big project, but it would be really cool to see multitasking running.
Post Edited (Dr_Acula) : 8/31/2009 12:20:56 AM GMT
Count me NO for packed drives for now (postedit)
re the packed sectors (4x128 per 512 SD sector)...
Yoda & LynchAJ: How will you do the unpacking if we progress to packed sectors? My thoughts are
* it is simpler and easier to just waste space and use 1x128 per 512
* less wear on the SD card or we have to implement smarts which I think is harder on your N8VEM
* we want to keep the SD card files the same for TriBlade, Morpheus, PropIO and N8VEM
* any extra config files required for different hardware can be on the SD card
* all files(drive files) will be under FAT16 on the SD card, so cards up to 2GB
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/31/2009 12:34:02 AM GMT
* wear issues on SD
* impact on N8VEM (Yoda & Andrew??)
* ramifications on writing back - how, is it delayed, power fail, speed, overheads, etc
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
So ok, keep the 32mb drives?
I'm not sure it makes much difference to speed anyway.
Can I just clarify, when you read a sector, does the sd card code send heaps of pulses first to somehow reset the card?