Parallax Forums
  HomeLog InRegisterCommunity CalendarSearch the ForumHelp
   
Parallax Forums > Public Forums > Propeller Chip > TriBladeProp PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC)  Forum Quick Jump
 
New Topic Post Reply Printable Version
849 posts in this thread.
Viewing Page :  
[ << Previous Thread | Next Thread >> ] | Show Newest Post First ]

Toby Seckshund
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2009
Total Posts : 477
  		   Posted 8/31/2009 7:00 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
I know I often demonstate raw ignorance ...

There I was, finally getting a chance to try out your code on BST, bright eyed, with bushy tail.

The first conditional else at the end of the con block (rr107) and there it is "Expected Unique Nane..." error

Eyes dulled by welling tears, tail flattened.

Style and grace : Nil point

Back to Top
 

Yoda
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2009
Total Posts : 61
  		   Posted 8/31/2009 7:39 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Cluso, et al. : I was never proposing to do delayed writes. I think Heater is doing the way I proposed, you write on every write but sometimes you may need to do a read before the write. If it is sequential write you will do one read every 4 writes. Cluso, I understand that there will be 4 times as many writes to a sector but I don't think think this will kill the SD as compared to like a camera or cell phone usage of an SD, unless you are doing some serious data writing from a program.

James, I would not carried away with the number and size of disks. Heater is correct on both counts. 1) you really eat lots of memory that some programs require and 2) large disks become very unmanageable with no directories. I think we should also as Toby suggested get out of the notion of floppies and hard drives as they are all on uSD and are just block devices with different sizes. I really think 4 block devices are plenty and challenging enough to manage. When we are on CPM3 one of those could be a 512MB drive so that should satisfy you thirst for space - good luck managing it - you will find it challenging.

Dave
Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
  		   Posted 8/31/2009 7:51 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
PCB Layout - no ZiCog tonight & now bedtime.
 
Toby: Are you using the latest bst.exe? I have compiled _rr107 successfully. I just checked the package and it compiles correctly. I also note James has compiled it (can see his photo). Are you compiling for the TriBlade?? 
 
The big discussion about floppies v hard drives is because CPM treats floppies as character devices and is therefore very slow. Hard drives are treated as block drives and much faster. Also, Floppies have sector skewing meaning it does not read each successive sector. We want to just use hard drives within CPM even if it is really a floppy image (converted or not) because we want the speed. Hope this answers you questions.
 
Heater: I am happy to go with the packed sectors. We can always revert if there are issues. The hdp_0 does not appear to be working.
 
James & Heater: My code no longer loads all 64KB of SRAM from SD. Version rr107 code now clears the RAM $0000-FFFF, places a JMP $FF00 at $0000, loads the file DSKBOOT_.ROM (its the DSKBOOT.COM file which is 256 bytes long i.e. 1x512 byte SD sector) into $FF00-$FFFF and starts ZiCog which of course executes $0000 which immediately jumps to $FF00. Quite fast now, even with my slow SD driver. BTW, if a RamDisk is used, then the SRAM $10000-$7FFFF for 512KB SRAM or $10000-$FFFFF for 1MB SRAM is preloaded with $E5 to simulate an empty formatted drive. James, that is what the code you posted above is doing. I use tbp2 as a block driver because it is in pasm so it is very fast for block moves. I have not yet added a "clear/fill sram" function which will be even faster.
 
The following just enables the SD driver (it is already resident)
'read the DSKBOOT_.ROM file (256 bytes)
  r := sd.initSDCard(spiDO,spiClk,spiDI,spiCS)          'init SD card, but do not restart cog
  CheckError(r)

The following reads the contents (256 bytes) from drive[16] which has been preloaded with the base sector address on the card for the file DSKBOOT_.ROM (DSKBOOT.COM)
  r := sd.readSDCard(drive_base[16], @buff, 256)        'get 256 bytes
  CheckError(r)

The following tristates the SD card bus, but keeps the SD pasm driver active, so we do not have to reload the cog
  r := sd.stopSDCard                                    'stop SD card, but do not stop cog
  CheckError(r)

The following re-activates the SRAM bus in the TriBlade driver
'copy the 256 bytes to $FF00-$FFFF in sram
  r := tbp2.active                                      'activate the bus
  CheckError(r)

The following copies 256 bytes from the buffer to SRAM $FF00 (these are the 256 bytes read from the DSKBOOT file above)
  r := tbp2.DoCmd("W", @buff, $FF00, 256)               'write to sram
  CheckError(r)

The following clears an 8KB hub buffer to $E5
'now set the buffer to "$E5" and fill the remainder of sram for use as empty RamDisk
  repeat i from 0 to count - 1                          'set 8KB block = $E5
    buff[ i ] := $E5

The following copies the 8KB hub buffer ($E5) to SRAM in 8KB blocks from 64KB to 512KB or 1MB, depending of the size of SRAM.
This is used for the RamDisk and is a blank formatted drive.
  repeat i from b1 to b2 - 1                            '8 to 63/127: write 56/120 x 8KB blocks of sram above first 64KB
    r := tbp2.DoCmd("W", @buff, i * count, count)       'write to sram
    CheckError(r)

Hope this explains the above code.

 

Links to other interesting threads:
Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
  		   Posted 8/31/2009 8:30 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Joda:

Yes, that is, NO delayed writes the rest as you say. I put my faith in the wear leveling algorithms builtinto SD cards. Especially has we can have lots of free space on the cards for it to jugle blocks in.

I'm aiming to implement 2 * 1Mb and 1 * 8Mb disks, that would have been "high end" in 1980, if anyone wants to expand/change that they are welcome.
Should be easy now we have the disk geometry params in Spin.

Having only a few disks is not such a bad limitation IF they can be selected by the user before starting Z80 emulation. One may have a hundred different "floppies" on the SD and just load up the ones required. You remember, we used to have to change floppies:)

Which means that...We should be able to escape from a running emulation into an emulator command mode so as to change disk selections etc. Contol-E for example like SIMH.

Cluso:

Packed sectors hurrah ! We are in turbo mode.

P.S. I may have fibbed about the boot time from power up. I am loading RAM from BST and watching boot time from end of load to A> prompt.
I am not counting the time it takes a Prop to load from EEPROM. Would you believe I still don't have one !

For me, the past is not over yet.

Back to Top
 

Toby Seckshund
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2009
Total Posts : 477
  		   Posted 8/31/2009 11:48 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Heater

I just tried James's version via BSTc and it ran through ok. I'll catch on to this computer stuff, one day.

Style and grace : Nil point

Back to Top
 

Toby Seckshund
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2009
Total Posts : 477
  		   Posted 8/31/2009 12:16 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Heater

I "ticked" the extensons and generic opt boxes and it runs though.

now, what needs to be on the SD card, and how do I get it in the right places??

Style and grace : Nil point

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
  		   Posted 8/31/2009 2:10 PM (GMT -8)    Quote This PostAlert An Admin About This Post.

Toby: Great news that it compiles. bst should also work.

Postedit from Heater: Do check the "Non-Parallax compatible extensions" and "Override global compiler optimizations" in the Project options dialogue.

For the SD card: Get a converter for your PC. There are two ways for this, one is an SD to microSD converter but you will require a PC that has an SD reader. Otherwise, you can get a microSD to USB converter. Both are cheap at camera and computer stores or eBay (or Officeworks in Australia) I have posted photos. You will require a microSD "uSD" with 2GB or less. Format it with windows with 32KB clusters and FAT16 (I think my assembly instructions at the top of this thread has this in them). Now copy the following files to the uSD... (needs to be done to a reformatted uSD as the files must be contiguous to work correctly!)

  • DSKBOOT_.ROM           (small boot program)
  • DRIVE__A.DSK             (a copy of either DRVCPM_2.DSK or DRVCPM_3.DSK - use DRVCPM_2.DSK for now)
  • DRIVE__B.DSK
  • DRIVE__C.DSK
  • DRIVE__D.DSK
  • DRIVE__E.DSK
  • DRIVE__F.DSK
  • DRVCPM_2.DSK            (CPM 2.2 floppy)
  • DRVCPM_3.DSK            (CPM 3    floppy)
  • HDRIVE_I.DSK
  • HDRIVE_J.DSK

The first and last 2 are in a recent post (page or 2 back). The rest are in 2 files at the top of this thread with instructions. This should get the A> prompt. Then read this and the ZiCog thread - look for screen shots and in the posts above you should see instructions for MBASIC. A better way maybe to search the wiki for CPM commands.

Enjoy cool

Heater: I think we need at least 4 Hard Disks, maybe 6-8 (as we want CPM2, CPM3, MPM) although I guess we don't need all these online at once. So: 1 x 1MB, 1 x 448KB/960KB/???KB RamDrive, 1 x 8MB, 1 x 8MB(or larger). Your thoughts??

 


Links to other interesting threads:
  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 10:17:36 PM GMT

Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
  		   Posted 8/31/2009 3:18 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Re The hdp_0 does not appear to be working.

I'm at work now so can't check the code at home, but I noticed last night that two of the parameters in the hdp_0 were commented out. They are the same two that won't display properly on this forum and I'm wondering if they have been copied onto a forum post then copied back into the code and got corrupted and then commented out? Maybe I'm going off on a tangent here but hdp_0 was different to the other 3.

There is a lot to be said for creating 'directories' by keeping files in floppy/hard drive package sizes. eg a wordstar disk, mbasic, sbasic, c, fortran like the way the simh packages are organised. Fascinating comment earlier about putting lots of disk images from the simh on the sd card (even all of them?) and then just using the ones you want.

I wonder, could you change disks on the fly with a special command? eg an 'out' to a port that gets trapped by the spin code and then changes the disk. Then write a small program in cp/m (bdsc, sbasic, bascom) that you can run and it maybe gives you a list of the disks and you can select which one you now want to be 'disk B' or whatever. It could print out a 'directory' of all the available disk images. That would give cp/m a directory structure without having to hack cp/m! I can think about how such a program would work if it is:

a) possible to remount a disk after the zicog has been started and
b) it is possible to talk to the spin operating system from within cp/m using some in and out statements (thinking 4 ports - two in and two out, 'do you have a byte' and 'byte' for each) and for the spin code to return, 1 byte at a time, a list of all the disk images, and receive, 1 byte at a time, the name of a disk image.
Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
  		   Posted 8/31/2009 3:48 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
No James. It was me trying to limit the size of the drive, but STAT did not report any difference, so I just left what I had done commented out for heater to see if he could get it to work. I had tried hdp_1 also.

re changing SD on the fly... Lots of risks here. Changing a disk (i.e. file) on the fly maybe. But let's walk first.

Links to other interesting threads:
Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
  		   Posted 8/31/2009 8:05 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Re "re changing SD on the fly... Lots of risks here. Changing a disk (i.e. file) on the fly maybe. But let's walk first."

I was thinking of changing a file on the fly. Not changing the physical sd card.

At the simplest level changing a file might involve sending some commands back to the spin code that changes the array that holds the .dsk names of the disk files. Then just do a cold boot by jumping right back to the beginning of the spin code. Crude I know, and probably there is a more elegant method (? a warm boot). But yes, walking first, and agreeing on how many floppy drives and how many hard drives and what format etc would need to come first.

Toby, have you got an A> yet?
Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
  		   Posted 8/31/2009 9:28 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
CP/M has the capability, or at least some CBIOSs did have, of detecting disk changes and rescanning the directories. I don't see any support for this in our CBIOSX and I don't see how it can be made to work without interrupts to the Z80, which we are almost certainly never going to implement. Checking for interrupts in the emulation loop would be yet another slow down.

BUT I can imagine that add some user interface to the emulation such that Control-E kills the emulation, allows the user to map a different disk image to a drive and then restart the emulation. Rather like you would do in SIMH.

Now whether we can be more sophisticated and not kill the emulation but just pause it and then change the disk I don't know yet. Again when you allow the emulation to continue from where it left off how would it know a disk has changed ?

News:

I just managed to get the Mits Altair 1M floppy disk parameters into one of our dpb blocks.
It now shows up as a 1M drive C:

There is a little problem here as I cannot create a 1M floppy to use as a boot disk.
Problem is if you create a 1M boot floppy under SIMH as normal then it has Altair floppy sector skewing on it. The hard disk driver in CBIOS does not use sector skewing so it would be unreadable by ZiCog.

Anyone got any idea how to get SIMH to deal with an Altair geometry floppy but without skew ?

So for now I'm stuck with the backward situation of having an 8M boot disk as drive A: and the rest can be 1M or 8M.

For me, the past is not over yet.

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
  		   Posted 8/31/2009 11:23 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Great news... moving forward :-)

If you have both the floppy and hard drive under SIMH, could you not have a blank 1MB hard drive ($E5) and put the boot system onto it and PIP all files from the floppy to it. This would take care of the sector skewing and 137 byte format in one hit ????

BTW how did you get the hdp running? My drive C: is still a floppy.

Links to other interesting threads:
Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
  		   Posted 9/1/2009 2:44 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Maybe I'm missing a point here but I'm suffering from "chicken and egg" syndrome.

You may be right but I can't convince myself of why yet.

However I just found I could attach a floppy disk image to SIMH as a dsk or an hdsk and it comes up readable both ways!!

This tells me there is something going on here I don't understand yet.

Still, the boot tracks are identical on hard and floppy disks (skew does not apply) so a BOOTGENed 1MB floppy which is otherwise blank to E5 should boot up as a floppy or HD.

Time for an experiment...

For me, the past is not over yet.

Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
  		   Posted 9/1/2009 2:55 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Cluso: What are you running now?

Our normal old CBIOS (before I started removing floppy support) will always treat the first 8 drives as Altair floppies no matter what we put in those hdp tables. The first entry dpb_0 is always drive I:

What should we do to get your latest zicog_demo changes merged to the up and coming one from me ?
I stopped looking at the changes you made in 107 when I found the output of diff is over 900 lines long !!!
(yes I know many of those are comment indentation changes)

Now I'd like to put up a zicog_demo with
1) Packed disks
2) All Altair floppy driver code removed.
3) Changes to the dpb tables for 1M drives.
4) A few other lines here and there to support the new packed disk routines.

That's already a lot but its get worse.

There is now a new CBIOSX.COM.
And the the disk images in FAT have to change.

I/we need you to tweek the new packed HD routines for the TriBlade.

So should I just dump all this on you at some point !!!???

For me, the past is not over yet.

Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
  		   Posted 9/1/2009 4:51 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
How to make a bootable 1MB disk usable as a hdsk under SIMH and ZiCog.

I think I've cracked it. The trick is that in SIMH one can specify the geometry of hard drives before starting the emulator by putting something like this in the config file:

attach hdsk1 new.dsk
set hdsk1 geom=254/32/128

That is 254 tracks, 32 sectors, 128 bytes per sector. Just like an old Altair floppy but no 137 byte sectors.

You can then start SIMH and XFORMAT the new disk then BOOTGEN the boot sectors on to it.

It's a bit more tricky than that as you have to get the steps in the right order else either XFORMAT or BOOTGEN complains about the disk format with a sector error !!!

So here is a HOWTO document that shows a working example.

For me, the past is not over yet.



File Attachment :
HOWTO_make_a_bootable_1MB_HD.txt   2KB (text/plain)
This file has been downloaded 14 time(s).
Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
  		   Posted 9/1/2009 4:57 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Hmm, That is still not quite what we want as XFORMAT (or SIMH) has reserved a huge number of directory entries so it is probably laid out like an hdsk after all. BUT no skew anyway !

Perhaps we just have to crate the empty bootable disk under SIMH and then PIP the files on to it under ZiCog. More experiments .....

For me, the past is not over yet.

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
  		   Posted 9/1/2009 6:03 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Heater: I have been doing hardware so nothing on the ZiCog front from me. When you are done, send me your demo file.
Yes I tried to change the size of drives I & J with both hdp_0 and hdp_1 but no luck as it still reported 8MB. That was even after I started with $E5 and PIP.

Links to other interesting threads:
Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
  		   Posted 9/1/2009 6:19 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Doing some experiments changing the file size. Seems to be working as expected for drive I. Start with 8mb:


hdsk_dpb
dpb_0                           'Default 8MByte SIMH Altair HDSK params
:spt_low      BYTE      $20     'sectors per track (low byte)
:spt_high     BYTE      $00     'sectors per track (high byte)
:bsh          BYTE      $05     'data allocation Block SHift factor
:blm          BYTE      $1F     'data allocation block mask
:exm          BYTE      $01     'EXtent Mask
:dsm_low      BYTE      $F9     'maximum data block number (low_byte)      
:dsm_high     BYTE      $07     'maximum data block number (high_byte)    
:drm_low      BYTE      $FF     'total number of directory entries (low byte)
:drm_high     BYTE      $03     'total number of directory entries (high byte)
:al0          BYTE      $FF     'determine reserved directory blocks
:al1          BYTE      $00     'determine reserved directory blocks
:cks_low      BYTE      $00     'size of directory ChecK vector (low byte)
:cks_high     BYTE      $00     'size of directory ChecK vector (high byte)
:off_low      BYTE      $06     'number of reserved tracks (offset) (low byte)
:off_high     BYTE      $00     'number of reserved tracks (offset) (high byte)
sh          BYTE      $00     'Physical record SHift factor, CP/M 3
hm          BYTE      $00     'PHhysical record Mask, CP/M 3
:ss_low       BYTE      $80     'Sector Size (low byte)
:ss_high      BYTE      $00     'Sector Size (high byte)


Changed dsmhigh to 00 instead of 07 and left dsmlow at F9


Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes
MBASIC  COM   24K
1 File(s), occupying 24K of 416K total capacity
1023 directory entries and 392K bytes remain on I:
I>


Mind you, it is crashing now after expanding it back up to 8mb, so might need to start with a clean disk image there. But it does shrink down changing dsmlow and dsm high

Ok working now I've gone for a clean image and gone back to the original variables.

0 File(s), occupying 0K of 8136K total capacity
1024 directory entries and 8136K bytes remain on I:
I>

So - shrinking works, but expanding might need a clean image.

I tried some other combos with dsmlow and dsmhigh and they shrink and expand as expected in a proportional way, though I'm not quite sure how the maths works. 07F9H = 8136k

Post Edited (Dr_Acula) : 9/1/2009 2:28:31 PM GMT

Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
  		   Posted 9/1/2009 6:44 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
I think you have to be careful messing with those parameters they are all interrelated.

In my setup now I have no Altair floppy drives all goes through HD and those tables.
I have A: and B: defined as normal 8M drives. C: and D: are 1MB using the Altair floppy dpb entries I found in the CBIOSX.MAC.

My dpb tables are shown with the results below:


hdsk_dpb
dpb_0                           '8MByte Default SIMH Altair HDSK params
:spt_low      BYTE      $20     'sectors per track (low byte)
:spt_high     BYTE      $00     'sectors per track (high byte)
:bsh          BYTE      $05     'data allocation Block SHift factor
:blm          BYTE      $1F     'data allocation block mask
:exm          BYTE      $01     'EXtent Mask
:dsm_low      BYTE      $F9     'maximum data block number (low_byte)
:dsm_high     BYTE      $07     'maximum data block number (high_byte)
:drm_low      BYTE      $FF     'total number of directory entries (low byte)
:drm_high     BYTE      $03     'total number of directory entries (high byte)
:al0          BYTE      $FF     'determine reserved directory blocks
:al1          BYTE      $00     'determine reserved directory blocks
:cks_low      BYTE      $00     'size of directory ChecK vector (low byte)
:cks_high     BYTE      $00     'size of directory ChecK vector (high byte)
:off_low      BYTE      $06     'number of reserved tracks (offset) (low byte)
:off_high     BYTE      $00     'number of reserved tracks (offset) (high byte)
sh          BYTE      $00     'Physical record SHift factor, CP/M 3
hm          BYTE      $00     'PHhysical record Mask, CP/M 3
:ss_low       BYTE      $80     'Sector Size (low byte)
:ss_high      BYTE      $00     'Sector Size (high byte)
                                'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.

dpb_1                           'Default 8MByte SIMH Altair HDSK params
:spt_low      BYTE      $20     'sectors per track (low byte)
:spt_high     BYTE      $00     'sectors per track (high byte)
:bsh          BYTE      $05     'data allocation Block SHift factor
:blm          BYTE      $1F     'data allocation block mask
:exm          BYTE      $01     'EXtent Mask
:dsm_low      BYTE      $F9     'maximum data block number (low_byte)
:dsm_high     BYTE      $07     'maximum data block number (high_byte)
:drm_low      BYTE      $FF     'total number of directory entries (low byte)
:drm_high     BYTE      $03     'total number of directory entries (high byte)
:al0          BYTE      $FF     'determine reserved directory blocks
:al1          BYTE      $00     'determine reserved directory blocks
:cks_low      BYTE      $00     'size of directory ChecK vector (low byte)
:cks_high     BYTE      $00     'size of directory ChecK vector (high byte)
:off_low      BYTE      $06     'number of reserved tracks (offset) (low byte)
:off_high     BYTE      $00     'number of reserved tracks (offset) (high byte)
sh          BYTE      $00     'Physical record SHift factor, CP/M 3
hm          BYTE      $00     'PHhysical record Mask, CP/M 3
:ss_low       BYTE      $80     'Sector Size (low byte)
:ss_high      BYTE      $00     'Sector Size (high byte)
                                'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.

dpb_2                           '1MByte Altair mits2 floppy as HDSK params
:spt_low      BYTE      $20     '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      $EF     'maximum data block number (low_byte)
:dsm_high     BYTE      $01     'maximum data block number (high_byte)
:drm_low      BYTE      $FF     'total number of directory entries (low byte)
:drm_high     BYTE      $00     'total number of directory entries (high byte)
:al0          BYTE      $F0     'determine reserved directory blocks
:al1          BYTE      $00     'determine reserved directory blocks
:cks_low      BYTE      $00     'size of directory ChecK vector (low byte)
:cks_high     BYTE      $00     'size of directory ChecK vector (high byte)
:off_low      BYTE      $06     'number of reserved tracks (offset) (low byte)
:off_high     BYTE      $00     'number of reserved tracks (offset) (high byte)
sh          BYTE      $00     'Physical record SHift factor, CP/M 3
hm          BYTE      $00     'PHhysical record Mask, CP/M 3
:ss_low       BYTE      $80     'Sector Size (low byte)
:ss_high      BYTE      $00     'Sector Size (high byte)
                                'N.B. SS must be 128 for CP/M 2 can be varied for CP/M 3 hard disks.

dpb_3                           '1MByte Altair mits2 floppy as HDSK params
:spt_low      BYTE      $20     '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      $EF     'maximum data block number (low_byte)
:dsm_high     BYTE      $01     'maximum data block number (high_byte)
:drm_low      BYTE      $FF     'total number of directory entries (low byte)
:drm_high     BYTE      $00     'total number of directory entries (high byte)
:al0          BYTE      $F0     'determine reserved directory blocks
:al1          BYTE      $00     'determine reserved directory blocks
:cks_low      BYTE      $00     'size of directory ChecK vector (low byte)
:cks_high     BYTE      $00     'size of directory ChecK vector (high byte)
:off_low      BYTE      $06     'number of reserved tracks (offset) (low byte)
:off_high     BYTE      $00     'number of reserved tracks (offset) (high byte)
sh          BYTE      $00     'Physical record SHift factor, CP/M 3
hm          BYTE      $00     'PHhysical record Mask, CP/M 3
:ss_low       BYTE      $80     'Sector Size (low byte)
:ss_high      BYTE      $00     'Sector Size (high byte)




A>ls a:
Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes
ASM     COM    8K ! CPMBOOT COM   12K ! FORMAT  COM    4K ! MOVER   PRN    4K
BDOS    COM    4K ! CREF80  COM    4K ! GO      COM    0K ! PIP     COM    8K
BDOS    MAC   68K ! DDT     COM    8K ! HALT    COM    4K ! SHOWSEC COM    4K
BDOS    PRN  168K ! DIF     COM    4K ! HDSKBOOTMAC    8K ! STAT    COM    8K
BOOT    COM    4K ! DO      COM    4K ! L80     COM   12K ! SUBMIT  COM    4K
BOOT    MAC    4K ! DSKBOOT COM    4K ! LIB80   COM    8K ! SURVEY  COM    4K
BOOTGEN COM    4K ! DSKBOOT MAC    8K ! LOAD    COM    4K ! SURVEY  MAC   16K
CBIOSX  COM    4K ! DUMP    COM    4K ! LS      COM    4K ! SYSCOPY COM    4K
CBIOSX  MAC   52K ! EC8080  LIB    4K ! LU      COM   20K ! SYSCPM2 SUB    4K
CBIOSX  PRN  104K ! ECZ80ALLLIB    4K ! M80     COM   20K ! UNCR    COM    8K
CCP     COM    4K ! ECZ80DOCLIB    4K ! MC      SUB    4K ! UNERA   COM    4K
CCP     MAC   28K ! ED      COM    8K ! MCC     SUB    4K ! UNERA   MAC   16K
CCP     PRN   76K ! EX      MAC   56K ! MCCL    SUB    4K ! XFORMAT COM    4K
CFGCCP  LIB    4K ! EX8080  COM   12K ! MOVER   COM    4K ! XSUB    COM    4K
COPY    COM    4K ! EXZ80DOCCOM   12K ! MOVER   MAC    4K
59 File(s), occupying 880K of 8136K total capacity
951 directory entries and 7256K bytes remain on A:
A>ls b:
Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes
DSKBOOT MAC    8K
1 File(s), occupying 8K of 8136K total capacity
1023 directory entries and 8128K bytes remain on B:hdsk param
A>ls c:
Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes
MOVER   MAC    2K
1 File(s), occupying 2K of 984K total capacity
255 directory entries and 982K bytes remain on C:hdsk param
A>ls d:
Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes   Name    Ext Bytes
HDSKBOOTMAC    6K
1 File(s), occupying 6K of 984K total capacity
255 directory entries and 978K bytes remain on D:hdsk param
A>

For me, the past is not over yet.

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
  		   Posted 9/1/2009 7:39 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Nice work - I will have to try again :-) Maybe in the morning.

Links to other interesting threads:
Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
  		   Posted 9/4/2009 11:50 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Coming soon to the TriBlade...
New custom CBIOSX for ZiCog.
Eight hard disk driver for CP/M on SD.
6 * 8Mb + 1Mb Altair floppy style + 440K RAM for disk.
No Altair floppy support in BIOS.
Approx 1 second boot time.
New boot loader for hard disk boot (ZIBOOT.COM).
Just tidying and making the package now...


ZiCog 1.0_rc_3 on the Prop Demo Board
Starting disks (A:B:C:D:E:F:G:H:) ...
Passed, please wait...
Starting 8080 emulation...
Passed, please wait...
24K CP/M Version 2.2 (ZiCog, BIOS V1.27_Zi01, 8 HD, 05-Sep-2009)
A>b:
B>c:
C>d:
D>e:
E>f:
F>g:
G>h:
H>a:
A>survey
                *** System Survey (June 82) ***
Drive A: 924K bytes in 75 files with 7244K bytes remaining
Drive B: 32K bytes in 0 files with 8136K bytes remaining
Drive C: 32K bytes in 0 files with 8136K bytes remaining
Drive D: 32K bytes in 0 files with 8136K bytes remaining
Drive E: 32K bytes in 0 files with 8136K bytes remaining
Drive F: 32K bytes in 0 files with 8136K bytes remaining
Drive G: 8K bytes in 0 files with 984K bytes remaining
Drive H: 14K bytes in 1 files with 434K bytes remaining

Memory map:
0       8       16      24      32      40      48      56      64
|       |       |       |       |       |       |       |       |
 TTTTTTTTTTTTTTTTCCCBBBBBRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
T=TPA   C=CPM   B=BIOS or unassigned    R=ROM or bad
BIOS at 4E03    iobyte 00       drive 00        BDOS at 4006

24576 Bytes RAM         40958 Bytes ROM         16390 Bytes in TPA
1 Bytes Empty           65534 Total Active Bytes

Active I/O ports:
01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
.
.
.
254 Ports active
A>

For me, the past is not over yet.

Back to Top
 

Dr_Acula
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2008
Total Posts : 606
  		   Posted 9/5/2009 1:02 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
I'm following the progress eagerly - all very exciting. So, drive G is the floppy drive? Does that mean you are booting from the system tracks of drive A? And how are you creating the drive A image now?

www.smarthome.viviti.com/build

Post Edited (Dr_Acula) : 9/5/2009 9:49:39 AM GMT

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
  		   Posted 9/5/2009 2:35 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Very nice heater :-)

Links to other interesting threads:
Back to Top
 

heater
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2008
Total Posts : 1832
  		   Posted 9/5/2009 3:07 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Dr_A:

Thing is that all drives are now handled by the SIMH hard drive interface no matter what size/geometry they have. So they all get a speed up because the HD driver used DMA/block move. We can define whatever size/geometry we like in the dpb tables in Spin and attach them to whatever drive letter we like without having to hack and rebuild the CBIOS.

Also means that the disks have no sector skew which means our packed sector system gets to do a lot of sequential access's for more speed :)

I removed all the floppy driver support from the CBIOSX so as to keep the BIOS down to a reasonable size when adding more HDs. Eight should be enough (?)

Downside is that regular SIMH Altair floppy images are no longer usable.

Drive G: and H: are defined as two different size "floppies" by way of examples and to prove it works.

Currently the thing boots from drive A: The boot drive is actually set in the ROM boot loader code so we can make that flexible as well.

That drive A: is an exact copy of my SIMH I: drive put onto my SD card with no preprocessing:)

I create it by PIPing the files from a modified cpm2.dsk to I: under SIMH and then make it bootable with:

BOOTGEN CPMBOOT.COM I:

after having built a CP/M with the new version of CBIOSX.

Just cleaning up and testing and I'll put this up for your perusal.

For me, the past is not over yet.

Back to Top
 

Cluso99
We live onboard



Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2008
Total Posts : 2276
  		   Posted 9/5/2009 3:37 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Heater - your explanation makes it even better jumpin jumpin jumpin

Links to other interesting threads:
Back to Top
 
[ << Previous Thread | Next Thread >> ]
New Topic Post Reply Printable Version
849 posts in this thread.
Viewing Page :  
 
Forum Information
Currently it is Friday, November 20, 2009 11:23 PM (GMT -8)
There are a total of 393,738 posts in 55,521 threads.
In the last 3 days there were 81 new threads and 700 reply posts. View Active Threads
Who's Online
This forum has 17687 registered members. Please welcome our newest member, mark09.
52 Guest(s), 1 Registered Member(s) are currently online.  Details
pharseid
Forum powered by dotNetBB v2.42EC SP2.02
dotNetBB © 2000-2009

Need Support? | Forum Help Manual