rc_5.5b is the latest. I will not make any more changes until you are up and running. Well at least not publish any little experiments I may make.
Yeah, fancy HDPB set up is not a priority yet. I'm not to keen on putting more PASM in Zicog.spin that is not directly related to the CPU just so that it can be hidden in the Z80 RAM space. The code is long and ugly and complicated enough already. There must be a better way to recycle old PASM COG code RAM.
Looks like your file sector finding and sector viewing tool sounds like a great idea for us guys poking around in CP/M images and such. Perhaps it should include features from the FSRW demo as well, DIR, COPY, DELETE, etc. etc. (A whole DOS in fact [noparse]:)[/noparse])
By the way what is the status on changing updating the FAT / SPI drivers?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
By the way, I just discovered that there is a space of 418 bytes in the start of the FAT file system reserved for a message to be displayed when someone tries to boot a floppy disk that does not contain a bootable OS. You can see it with a hex sector editor (WinHex). The FAT formatter under Linux, mkdosfs, provides an option to set that string from a given file.
Sounds like an excellent place to put the CP/M disk image file sector position info. Preferably in human readable ASCII.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: I have placed the code to use TriBlade SD pins into rc 5.5b
So what do I need to run? (PropDemoBoard on TriBlade hardware)
* ZIBOOT.COM for compiling Zicog
* zipm2.dsk on the SD card and the known base address
* manually patch the SD block offset into zicog_cpm (do you have a version that uses the offset? current version 5.5b will require me to mod the code)
FWIW: I do not have SIMH running on my pc.
As soon as this is running I can get Zicog running properly on TriBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
So let me get this straight, you have zicog on a TriBlade but you are going to use HUB RAM instead of external.
You will need to get ZIBOOT.COM into the end of Z80 RAM and the jump FF00 ($C3, $00, $FF) placed at the beginning. So that will mean tweaking some #defines in zicog.spin around ram_z800 and ram_z800_end. Do check that ram_z80_end ends up sitting at address $6410.
Not to mention all those other #ifdefs around memory access...
Use zipm2.dsk, has a 25K CP/M build on it with support for 8 disks. Lets just start with the one disk.
Find the offset of zipm2.dsk and initialize hdsk_base_block to that. Eg
hdsk_base_block = 631 ' First block of first hard disk in SD.
hdsk_base_block has been in the code forever and used to be set to skip over the 8 floppy drives. It is now used in refresh_hd_cache to locate the disk. For multiple disks refresh_hd_cache will need tweaking to select the right one. Just now it assumes all the disks are in contiguous blocks after hdsk_base_block.
You should not need SIMH for this.
I have Windows Messenger open now if you want to hack and chat at the same time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It is working on the TriBlade hardware (uses the SD but NOT the SRAM for a 25K version of CPM2.2)
You will need to copy "zipm2.dsk" to the SD card and use the program to locate the file. You will then need to place the base address reported into the "zicog_cpm_rc5.5b_rr13.spin" at the label "hdsk_base_block = $202c7··············· ' First block of first hard disk in SD "zipm2.dsk". Change $202c7 to whatever is reported.
Compile and run
I am now working on getting the TriBlade running again using the SRAM, and will release code asap.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
64K CP/M version on it's way, but again I'm stuck at a client site for the rest of the day...
Looks like you found a bug with that offset thing. It's a wonder it doesn't crash something. Actually looking at it briefly now I can't see how it manages to work at all !!
The PropDemoBoard version needs fixing up to use the drive_base array for finding drives in the SD rather than just skipping over 8MB junks which now has it writing all over the FAT fs !!!. The drive base array will just have to be filled in manually for now.
I was pondering what to do about our problem re: the lack of HD support in the CP/M 3 BIOS.
I really don't want to have to put back the Altair floppy driver code in Spin or in the CP/M 2 CBIOSX. We had plenty of good reasons to remove it: Spin code size and complexity, BIOS code size and complexity, performance on SD, ease of migrating disk images from SIMH to ZiCog (The floppy images always need preprocessing) etc, etc. Plus if we want to select booting from floppy or HD then we need to use different boot ROM code....
I think it should be easy enough to put the HD driver into the CP/M 3 BIOS (actually only the loaders BIOS) provided we reserve drive A: as 1M floppy. That is drive A: would have Altair floppy geometry but would not be sector skewed and would use the HD driver.
So I'd like to propose that we reserve drives A: and B: as either two 1M floppy disks or a 1M floppy and a RAM disk.
The bigger hard drives would start at C: as is traditional in MSDOS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thanks heater. I couldn't understand the bug either? and couldn't see how it worked. I will leave that for you.
I will load the drive base array for you and repost the code.
Yes, I like the idea that A & B be floppy geometries without the sector skew and use the HD driver. I will use a subset of B (i.e. smaller) for the RamDisk. And start the traditional hard drives at C. So, I guess 2 floppies + 6 hard drives sounds good to me, but all go via the hard disk driver for speed. That way we will be able to mount other drives to vary whatever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Only 9 seconds to boot. Hard drives galore. Stable. Easy to compile. This is really really clever!!
ZiCog 1.0_rc_5.5b on the TriBladeProp v0.118
Starting Hdisks...
A:ZIPM2_64.DSK
B:ZICOG_B0.DSK
C:ZICOG_C0.DSK
D:ZICOG_D0.DSK
E:ZICOG_E0.DSK
F:ZICOG_F0.DSK
G:ZICOG_G0.DSK
H:ZICOG_H0.DSK
R:ZIBOOT .COM <-bootcode2
Loading SRAM...
Starting Z80 emulation...
Passed, please wait...
64K CP/M Version 2.2 (ZiCog, BIOS V1.27_Zi04, 8 HD, 10-Sep-2009)
SuperSUB V1.1
...
A>.; AUTOEXEC.SUB; PLACE INITIAL BOOT COMMANDS HERE
A>.
A>dir
A: DSKBOOT MAC : CBIOSX MAC : PIP COM : CCP MAC
A: CPMBOOT COM : MOVER PRN : BOOT COM : BOOT MAC
A: SYSCPM2 SUB : CFGCCP LIB : COPY COM : MC SUB
A: MCC SUB : CCP PRN : BDOS MAC : MOVER COM
A: ZIBOOT MAC : DIF COM : MOVER MAC : BDOS PRN
A: CBIOSX PRN : AUTOEXEC SUB : BDOS COM : SHOWSEC COM
A: XFORMAT COM : SURVEY MAC : DSKBOOT COM : CCP COM
A: MCCL SUB : CBIOSX COM : EC8080 LIB : ASM COM
A: ZIBOOT COM : CREF80 COM : DDT COM : DO COM
A: DUMP COM : ED COM : EX MAC : EX8080 COM
A: EXZ80DOC COM : FORMAT COM : GO COM : HALT COM
A: HDSKBOOT MAC : L80 COM : LIB80 COM : LOAD COM
A: LS COM : LU COM : M80 COM : ECZ80ALL LIB
A: ECZ80DOC LIB : STAT COM : SUBMIT COM : SURVEY COM
A: UNCR COM : UNERA COM : UNERA MAC : SYSCOPY COM
A: XSUB COM : BOOTGEN SPL : BOOTGEN COM
A>stat
A: R/W, Space: 7272k
A>
I added one tiny addition. A batch file called BST.BAT in the PC working folder.
So it compiles, downloads, and runs the terminal program all in one step. 12 seconds to compile and download and start running. So this makes modifying the code easy to do.
This is such a cool little board. Kudos to heater/cluso et al.
Here is ZiCog_rr120. It has an option to compile the TriBlade with floppies so that I can convert (via PIP) from a floppy sectored drive (128 bytes not 137) to a hard drive. I have done this for vedit, pascal and supercalc although I have yet to try them.
vedit and pascal are on ZICOG_VP.DSK and supercalc is on ZICOG_SC.DSK (hard drive format)
And here is a pic of all 8 hard drives
Also attached are the CPM2 and CPM3 files (hard drive format). You will need to change the code in FindSDblock to load them also. I noticed MBASIC was not on the A drive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I've been somewhat following this thread with interest for a while to see how far you guys would
actually take this concept. Super impressive stuff!
Is there any chance that one of you has posted a quick-starter for the rest of us to go
from somewhere is thread page 3 to up and running without migrating through all of the versions? [noparse]:)[/noparse] [noparse]:)[/noparse]
Heater & I are just trying to tidy up for a major V1.0 release.
However, just this page contains all the code and references to get this up and running, either on the Prop Demo Board or equivalent or the TriBlade. This includes all the SD files required. The bst compiler will have to be downloaded seperately though - follow the Tools link in my signature to find this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
OBC et al, that code I posted was from a download of Cluso's files into a brand new directory. And then just copied across my little batch file from a previous one. So it is very close to a complete package. No need to go back any further than what is on the latter part of this page.
Cluso, can you just go through again how the floppies and hard drives work? Or more specifically, you have the hard drive images which you have custom made from floppy images. I have a program, let's call it XMODEM.COM and it is sitting on an altair floppy drive image and also on an altair hard drive image (I copied it onto the floppy with R.COM and then transferred it to the hard drive with PIP). And I want to get it onto a disk image on the triblade so I can start doing xmodem file transfers. So I can use either the floppy or the hard drive. Which is easier to do? Do you now need to do any preprocessing on the drive images like with that vb6 program? Are the hard drive images 8mb or 32mb? (dumb question but I'm at work on a work computer so can't check it).
I know the answers to these questions as of 2 weeks ago. But this new setup is so much better that it obviously needs to become the standard! Probably the standard for the N8VEM/Propeller interface too.
V120 has the floppy code back in for the TriBlade only and only using a #define FloppySupport. Basically it is now to be regarded as a patched version that allows 8 floppies and 2 hdisks. It requires that the floppy disk provided by SIMH first be passed through VB6 to reformat the file into single 128 byte per 512 byte sector ready to be copied to the SD card. VB6 just defaults to creating a 32MB file only because that is what I had done in the past. Then, copy the file across to the uSD card (I use the SD slot in my PC and an uSD-SD adapter but you can use the uSD-USB adapter similarly). Now you modify v120 to select the #define FloppySupport and select the correct files to open as floppy drives (A: should remain unchanged as this is where you boot from) B:..H: and 2 blank hdisks filled with $E5's. Now compile, download and PIP I:=n:*.* where n: is the floppy drive you want to copy from. You can also use PIP J:=n:*.*· Sorry this is messy which is why I did the conversion for vedit, pascal and supercalc and posted the files. It is possible to remove the requirement for VB6 conversion by modifying the floppy code to accept 137 byte sectors.
Another way to do this could be to use SIMH directly on the pc. I have never loaded SIMH so cannot say what is involved here.
Once we know what is required, then I don't think it will be an issue to run a conversion once and post the various files in hdisk format. This way, they can all be copied to a new SD card once.
I noticed that I·downloaded two CPMPlus 20MB hdisk images from SIMH/CPM as parts 1 & 2 but I am unsure what they contain, nor the drive geometry. Any ideas???
ZiCog & uSD standard as of now:
FAT16 file structure (max 2GB cards)
standard Hard Disk(s) are packed file(s) 4x128 byte sectors per 512 byte SD sector, size 8MB (directly compatible with SIMH)
special Hard Disk(s) as above but size (geometries) can be specified in ZiCog hdp code
standard 8 x Hard Disks, no floppies
requires a boot file under FAT16 called "ZIBOOT.COM" (256 bytes loaded into $FF00 in ram and executed)
Disk files MUST be contiguous (consecutive sectors so ensure your uSD is reformatted first. If you do not delete, then no problems)
ZiCog current boot process:
locate all files required on uSD
clear ram $0000-$FFFF
at $0000 place JMP $FF00
at $FF00-$FFFF place first 256 bytes from file "ZIBOOT.COM"
start Z80 emulation at $0000
the A: drive contains a modified BIOS to continue·booting correctly (heater will have to comment further)
Hope this answers the questions for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
OBC. So sorry about the chaos in Z80 emulator on the Prop land.
There will be a release of version 1.0 "real soon now" complete with installation documentation.
As you see we have been recently breaking free of compatibility with the SIMH AltairZ80 project, for reasons of simplicity and efficiency on the "Propeller with SD" platform. So a lot of non-backwards compatible changes have been going on.
Actually I'd like to be able to have at least three variants for the big V1.0 that are basically "load and go"
a) A full up CP/M with 64K RAM and all possible disks for the TriBlade hardware.
b) A minimal CP/M that will at least get up to the A> prompt on a Prop Demo Board even without SD card. Just by way of convincing anyone with regular kit that it is possible.
c) A naked Z80 emulator demo with no CP/M or floppy HD drivers and other junk. Perhaps with just a simple Z80 program outputting to some LEDs. This just as an example of how to get the Z80 emulator running for those with no interest in CP/M. Any ZX81 builders out there ?
All suggestions welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Re "standard Hard Disk(s) are packed file(s) 4x128 byte sectors per 512 byte SD sector, size 8MB (directly compatible with SIMH?) "
The answer to that is Yes.
Ok, this was a real simple hack. I took Cluso's package from a few posts up. I wanted XMODEMP.COM on drive A for downloading. So - I noticed most of the drives were blank. Picked one at random (drive C). Put it into my altair simh folder and replaced drive j.dsk. Ran the simh, logged to drive J and did a R XMODEMP.COM off the PC into the drive image. Copied that new file image onto the sd card and renamed it ZICOG_C0.DSK.
Then fired up the prop again and copied it from drive C to drive A.
I only need to go through this once. Now I have XMODEMP.COM on drive A, I can transfer files using any generic terminal program.
Attached is xmodem.com (rename it back from a .txt as the forum doesn't allow .com files). It is the same as xmodem but the delays have been tweaked for the speed of the zicog.
What I can report is that xmodem transfers are now as fast as the baud rate. There are very slight pauses every 10k or so while things are written to disk. It is amazingly fast!
So - for mass transfer of lots of files, copy a disk image using an sd card reader. For transfer of one or two files, use xmodem.
mbasic is now loading as fast as the N8VEM, and changes between drives are also as fast. This is such an amazing step forward, it makes ram disks almost obsolete. Which means maybe the ram chip can be used for other things, eg MP/M?
Final little speedup - there is a three second delay at bootup to allow for slow terminals. I just commented this out and the bootup time is now only about 6 seconds.
Final little speedup - there is a three second delay at bootup to allow for slow terminals. I just commented this out and the bootup time is now only about 6 seconds.
If you put -f on your bstc command line you might get lucky and have it go even faster. That enables double baudrate downloads. I use it by default here, but I'm not sure how well it will work on Windows. Can't hurt to try anyway. I've seen it make between 15-25% reductions in download times.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Addit. To simplify that even further, I took the drive A image and have put two new files on it:
XMODEMP.COM for file transfers
DIRX.COM for a DIR that gives file sizes as well.
Zip is attached. Cluso, would you mind testing this is otherwise the same file as your A image, and if it is ok then maybe use this one from now on? Then we can have a package that is ready for download using any generic terminal program and you never need to worry about modifying drive images etc.
Addit: BradC - my limiting factor with baud rates is now my physical cable which is 2 metres of ribbon cable and only can handle 38k. It is plenty fast enough for me. Downloads of the propeller program as such are blindingly fast. Ditto file transfers in CP/M. And for most everyone else, they will be able to use 115k which is even faster.
Brad: I still cannot get bst gui to recognise my prop - I have to outout a binary and load with PropTool, then go to PropTerminal :-(
It is on COM13 and I am running Vista.
Drac: Nice work. I will have to add XMODEM.COM to the A: for the V1.0 release.
Drac: Our posts crossed. I will check out shortly and repost. I thought SIMH could do the transfer to a hard drive image
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I was thinking about a zicog disk compilation. You may notice the zipm2.dsk is customized from the SIMH cpm2.dsk. I removed most stuff not required for rebuilding CP/M itself and it contains all the customizations to CBIOSX, SYSCPM2 etc I have made.
So any suggestions as to what to include, XMODEM for example ?
There are some programs I cannot run on the Pro Demo Board as they require Z80 or more memory.
XFORMAT for formatting the disks for example.
The SYSCPM2.SUB script should rebuild CP/M and install it to disk on a TriBlade now. We should be self hosting. (N.B. syscpm2 needs a couple of lines changing to use drive A: instead of I[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
To Cluso, re the SIMH which I think you don't have, what I have done is taken my working SIMH drive files and stripped it right back so it fits in a zip small enough to post on the forum. So - just drive A (floppy) and drive I (hard). See attached.
There are two batch files.
ALTAIRALL.BAT opens in a dos window. Useful for quick and simple experiments that don't need a VT100 terminal
ALTAIRALLTELNET. BAT opens ready for connection to a terminal program. Useful for games and wordstar that use VT100 escape codes to move the cursor around. Then open teraterm or hyperterminal or whatever and connect to TCP/IP rather than to COM1 or COM2. Select port 23, and you can leave the IP address blank. This then allows wordstar to work on the simh.
(Telnet probably could allow access anywhere in the world if you opened the port on the router).
Drive I drops straight into the zicog. So useful for mass transfer of files.
Quick and simple terminal program that can run VT100 codes and do xmodem transfers. Boots much faster than hyperterminal and no questions at bootup once you have saved settings. I put a command in the bst batch file so it compiles then runs teraterm. So a compile process is just a double click on a .bat file and then the terminal is running with the A> prompt ready to go.
Drac: Thanks for the code.
Yes, I have already made the "." a #define ShowDiskWrites.
As the A: drive is now an 8MB hard drive, we can place other programs on it. I think just the base ones though (like DIRX, XMODEMP, MBASIC and maybe a few other utilities) and anyone can add whatever else they require from other disks using PIP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
Yeah, fancy HDPB set up is not a priority yet. I'm not to keen on putting more PASM in Zicog.spin that is not directly related to the CPU just so that it can be hidden in the Z80 RAM space. The code is long and ugly and complicated enough already. There must be a better way to recycle old PASM COG code RAM.
Looks like your file sector finding and sector viewing tool sounds like a great idea for us guys poking around in CP/M images and such. Perhaps it should include features from the FSRW demo as well, DIR, COPY, DELETE, etc. etc. (A whole DOS in fact [noparse]:)[/noparse])
By the way what is the status on changing updating the FAT / SPI drivers?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Sounds like an excellent place to put the CP/M disk image file sector position info. Preferably in human readable ASCII.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
So what do I need to run? (PropDemoBoard on TriBlade hardware)
* ZIBOOT.COM for compiling Zicog
* zipm2.dsk on the SD card and the known base address
* manually patch the SD block offset into zicog_cpm (do you have a version that uses the offset? current version 5.5b will require me to mod the code)
FWIW: I do not have SIMH running on my pc.
As soon as this is running I can get Zicog running properly on TriBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
So let me get this straight, you have zicog on a TriBlade but you are going to use HUB RAM instead of external.
You will need to get ZIBOOT.COM into the end of Z80 RAM and the jump FF00 ($C3, $00, $FF) placed at the beginning. So that will mean tweaking some #defines in zicog.spin around ram_z800 and ram_z800_end. Do check that ram_z80_end ends up sitting at address $6410.
Not to mention all those other #ifdefs around memory access...
Use zipm2.dsk, has a 25K CP/M build on it with support for 8 disks. Lets just start with the one disk.
Find the offset of zipm2.dsk and initialize hdsk_base_block to that. Eg
hdsk_base_block = 631 ' First block of first hard disk in SD.
hdsk_base_block has been in the code forever and used to be set to skip over the 8 floppy drives. It is now used in refresh_hd_cache to locate the disk. For multiple disks refresh_hd_cache will need tweaking to select the right one. Just now it assumes all the disks are in contiguous blocks after hdsk_base_block.
You should not need SIMH for this.
I have Windows Messenger open now if you want to hack and chat at the same time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It is working on the TriBlade hardware (uses the SD but NOT the SRAM for a 25K version of CPM2.2)
You will need to copy "zipm2.dsk" to the SD card and use the program to locate the file. You will then need to place the base address reported into the "zicog_cpm_rc5.5b_rr13.spin" at the label "hdsk_base_block = $202c7··············· ' First block of first hard disk in SD "zipm2.dsk". Change $202c7 to whatever is reported.
Compile and run
I am now working on getting the TriBlade running again using the SRAM, and will release code asap.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/13/2009 7:28:09 AM GMT
Uses new blocked files (4 x 128 sectors per 512 byte SD sector).
Files are attached for the ZiCog TriBlade v1.0_rc5.5b_rr116 software (requires bst for compilation)
Files are attached for the uSD files. These must be contiguous files, so preferably reformat your uSD card first and then copy these files to it.
Note:
- This version only permits 25K CPM2.2 to run. Heater: can you get me a 64KB version please?
- RamDisk is not running - I am going to implement a write-through RamDisk (so that any writes will also be written to the SD to keep it up to date)
- The new fsrw is still not running
- This can also be compiled to run on TriBlade without the SRAM (just uses the SD drive and 25KB hub ram for Z80 ram)
Heater: At lines 1005-6 in the·refresh_hd_cache routine there is an offset that I do not understand - will this overwrite the end of the buffer???▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
64K CP/M version on it's way, but again I'm stuck at a client site for the rest of the day...
Looks like you found a bug with that offset thing. It's a wonder it doesn't crash something. Actually looking at it briefly now I can't see how it manages to work at all !!
The PropDemoBoard version needs fixing up to use the drive_base array for finding drives in the SD rather than just skipping over 8MB junks which now has it writing all over the FAT fs !!!. The drive base array will just have to be filled in manually for now.
I was pondering what to do about our problem re: the lack of HD support in the CP/M 3 BIOS.
I really don't want to have to put back the Altair floppy driver code in Spin or in the CP/M 2 CBIOSX. We had plenty of good reasons to remove it: Spin code size and complexity, BIOS code size and complexity, performance on SD, ease of migrating disk images from SIMH to ZiCog (The floppy images always need preprocessing) etc, etc. Plus if we want to select booting from floppy or HD then we need to use different boot ROM code....
I think it should be easy enough to put the HD driver into the CP/M 3 BIOS (actually only the loaders BIOS) provided we reserve drive A: as 1M floppy. That is drive A: would have Altair floppy geometry but would not be sector skewed and would use the HD driver.
So I'd like to propose that we reserve drives A: and B: as either two 1M floppy disks or a 1M floppy and a RAM disk.
The bigger hard drives would start at C: as is traditional in MSDOS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I will load the drive base array for you and repost the code.
Yes, I like the idea that A & B be floppy geometries without the sector skew and use the HD driver. I will use a subset of B (i.e. smaller) for the RamDisk. And start the traditional hard drives at C. So, I guess 2 floppies + 6 hard drives sounds good to me, but all go via the hard disk driver for speed. That way we will be able to mount other drives to vary whatever.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The possible bug is interesting because if I remove the block_offset it fails. ???? What am I missing???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Heater - thanks for the 64KB version of the hdisk
Now just have to get the other CPM files into the correct blocked hdsk format.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Only 9 seconds to boot. Hard drives galore. Stable. Easy to compile. This is really really clever!!
I added one tiny addition. A batch file called BST.BAT in the PC working folder.
bstc -p2 -d COM1 -e -Ox zicog_cpm_rc5.5b_rr118.spin
C:\N8VEM\TERATER\TERATERM.EXE
pause
So it compiles, downloads, and runs the terminal program all in one step. 12 seconds to compile and download and start running. So this makes modifying the code easy to do.
This is such a cool little board. Kudos to heater/cluso et al.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
vedit and pascal are on ZICOG_VP.DSK and supercalc is on ZICOG_SC.DSK (hard drive format)
And here is a pic of all 8 hard drives
Also attached are the CPM2 and CPM3 files (hard drive format). You will need to change the code in FindSDblock to load them also. I noticed MBASIC was not on the A drive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/15/2009 2:24:27 PM GMT
I will have to dig out my Turbo Pascal manual out (if I still have v3 - I have v5.0 complete but it was for the PC).
FOUND - My books and original disks for Turbo Pascal V3, V4 & V5 (no V4 book :-( )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/15/2009 2:58:06 PM GMT
I've been somewhat following this thread with interest for a while to see how far you guys would
actually take this concept. Super impressive stuff!
Is there any chance that one of you has posted a quick-starter for the rest of us to go
from somewhere is thread page 3 to up and running without migrating through all of the versions? [noparse]:)[/noparse] [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
However, just this page contains all the code and references to get this up and running, either on the Prop Demo Board or equivalent or the TriBlade. This includes all the SD files required. The bst compiler will have to be downloaded seperately though - follow the Tools link in my signature to find this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Cluso, can you just go through again how the floppies and hard drives work? Or more specifically, you have the hard drive images which you have custom made from floppy images. I have a program, let's call it XMODEM.COM and it is sitting on an altair floppy drive image and also on an altair hard drive image (I copied it onto the floppy with R.COM and then transferred it to the hard drive with PIP). And I want to get it onto a disk image on the triblade so I can start doing xmodem file transfers. So I can use either the floppy or the hard drive. Which is easier to do? Do you now need to do any preprocessing on the drive images like with that vb6 program? Are the hard drive images 8mb or 32mb? (dumb question but I'm at work on a work computer so can't check it).
I know the answers to these questions as of 2 weeks ago. But this new setup is so much better that it obviously needs to become the standard! Probably the standard for the N8VEM/Propeller interface too.
Cheers, James
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
V120 has the floppy code back in for the TriBlade only and only using a #define FloppySupport. Basically it is now to be regarded as a patched version that allows 8 floppies and 2 hdisks. It requires that the floppy disk provided by SIMH first be passed through VB6 to reformat the file into single 128 byte per 512 byte sector ready to be copied to the SD card. VB6 just defaults to creating a 32MB file only because that is what I had done in the past. Then, copy the file across to the uSD card (I use the SD slot in my PC and an uSD-SD adapter but you can use the uSD-USB adapter similarly). Now you modify v120 to select the #define FloppySupport and select the correct files to open as floppy drives (A: should remain unchanged as this is where you boot from) B:..H: and 2 blank hdisks filled with $E5's. Now compile, download and PIP I:=n:*.* where n: is the floppy drive you want to copy from. You can also use PIP J:=n:*.*· Sorry this is messy which is why I did the conversion for vedit, pascal and supercalc and posted the files. It is possible to remove the requirement for VB6 conversion by modifying the floppy code to accept 137 byte sectors.
Another way to do this could be to use SIMH directly on the pc. I have never loaded SIMH so cannot say what is involved here.
Once we know what is required, then I don't think it will be an issue to run a conversion once and post the various files in hdisk format. This way, they can all be copied to a new SD card once.
I noticed that I·downloaded two CPMPlus 20MB hdisk images from SIMH/CPM as parts 1 & 2 but I am unsure what they contain, nor the drive geometry. Any ideas???
ZiCog & uSD standard as of now:
ZiCog current boot process:
Hope this answers the questions for now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/16/2009 8:31:51 AM GMT
There will be a release of version 1.0 "real soon now" complete with installation documentation.
As you see we have been recently breaking free of compatibility with the SIMH AltairZ80 project, for reasons of simplicity and efficiency on the "Propeller with SD" platform. So a lot of non-backwards compatible changes have been going on.
Actually I'd like to be able to have at least three variants for the big V1.0 that are basically "load and go"
a) A full up CP/M with 64K RAM and all possible disks for the TriBlade hardware.
b) A minimal CP/M that will at least get up to the A> prompt on a Prop Demo Board even without SD card. Just by way of convincing anyone with regular kit that it is possible.
c) A naked Z80 emulator demo with no CP/M or floppy HD drivers and other junk. Perhaps with just a simple Z80 program outputting to some LEDs. This just as an example of how to get the Z80 emulator running for those with no interest in CP/M. Any ZX81 builders out there ?
All suggestions welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The answer to that is Yes.
Ok, this was a real simple hack. I took Cluso's package from a few posts up. I wanted XMODEMP.COM on drive A for downloading. So - I noticed most of the drives were blank. Picked one at random (drive C). Put it into my altair simh folder and replaced drive j.dsk. Ran the simh, logged to drive J and did a R XMODEMP.COM off the PC into the drive image. Copied that new file image onto the sd card and renamed it ZICOG_C0.DSK.
Then fired up the prop again and copied it from drive C to drive A.
I only need to go through this once. Now I have XMODEMP.COM on drive A, I can transfer files using any generic terminal program.
Attached is xmodem.com (rename it back from a .txt as the forum doesn't allow .com files). It is the same as xmodem but the delays have been tweaked for the speed of the zicog.
What I can report is that xmodem transfers are now as fast as the baud rate. There are very slight pauses every 10k or so while things are written to disk. It is amazingly fast!
So - for mass transfer of lots of files, copy a disk image using an sd card reader. For transfer of one or two files, use xmodem.
mbasic is now loading as fast as the N8VEM, and changes between drives are also as fast. This is such an amazing step forward, it makes ram disks almost obsolete. Which means maybe the ram chip can be used for other things, eg MP/M?
Final little speedup - there is a three second delay at bootup to allow for slow terminals. I just commented this out and the bootup time is now only about 6 seconds.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
If you put -f on your bstc command line you might get lucky and have it go even faster. That enables double baudrate downloads. I use it by default here, but I'm not sure how well it will work on Windows. Can't hurt to try anyway. I've seen it make between 15-25% reductions in download times.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
XMODEMP.COM for file transfers
DIRX.COM for a DIR that gives file sizes as well.
Zip is attached. Cluso, would you mind testing this is otherwise the same file as your A image, and if it is ok then maybe use this one from now on? Then we can have a package that is ready for download using any generic terminal program and you never need to worry about modifying drive images etc.
Addit: BradC - my limiting factor with baud rates is now my physical cable which is 2 metres of ribbon cable and only can handle 38k. It is plenty fast enough for me. Downloads of the propeller program as such are blindingly fast. Ditto file transfers in CP/M. And for most everyone else, they will be able to use 115k which is even faster.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/16/2009 8:26:20 AM GMT
It is on COM13 and I am running Vista.
Drac: Nice work. I will have to add XMODEM.COM to the A: for the V1.0 release.
Drac: Our posts crossed. I will check out shortly and repost. I thought SIMH could do the transfer to a hard drive image
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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/16/2009 8:30:48 AM GMT
BTW there is LS on the A: that displays files and size.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
That image attached.
Re LS, this is what happens when you resurrect CP/M from a 1984 disk. The file I call DIRX.COM seems to be identical to LS.COM! So - use either.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
If you are using it to download a propeller it is already handling 115k quite nicely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
So any suggestions as to what to include, XMODEM for example ?
There are some programs I cannot run on the Pro Demo Board as they require Z80 or more memory.
XFORMAT for formatting the disks for example.
The SYSCPM2.SUB script should rebuild CP/M and install it to disk on a TriBlade now. We should be self hosting. (N.B. syscpm2 needs a couple of lines changing to use drive A: instead of I[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
To Cluso, re the SIMH which I think you don't have, what I have done is taken my working SIMH drive files and stripped it right back so it fits in a zip small enough to post on the forum. So - just drive A (floppy) and drive I (hard). See attached.
There are two batch files.
ALTAIRALL.BAT opens in a dos window. Useful for quick and simple experiments that don't need a VT100 terminal
ALTAIRALLTELNET. BAT opens ready for connection to a terminal program. Useful for games and wordstar that use VT100 escape codes to move the cursor around. Then open teraterm or hyperterminal or whatever and connect to TCP/IP rather than to COM1 or COM2. Select port 23, and you can leave the IP address blank. This then allows wordstar to work on the simh.
(Telnet probably could allow access anywhere in the world if you opened the port on the router).
Drive I drops straight into the zicog. So useful for mass transfer of files.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/16/2009 9:32:16 AM GMT
Quick and simple terminal program that can run VT100 codes and do xmodem transfers. Boots much faster than hyperterminal and no questions at bootup once you have saved settings. I put a command in the bst batch file so it compiles then runs teraterm. So a compile process is just a double click on a .bat file and then the terminal is running with the A> prompt ready to go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Way back when the emulation was slow I added a line that printed a "." whenever it wrote to the sd card.
hdskWrite: 'UART.str(string("hdsk write")) 'crlf 'UART.tx(".")The new emulation is so incredibly fast that this isn't really needed any more. Do you think it is time to comment it out?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Yes, I have already made the "." a #define ShowDiskWrites.
As the A: drive is now an 8MB hard drive, we can place other programs on it. I think just the base ones though (like DIRX, XMODEMP, MBASIC and maybe a few other utilities) and anyone can add whatever else they require from other disks using PIP.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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