James: This error is >32KB (see the bottom of the screen for the error details) - Oh, you are using the command line version. Maybe there is a more detailed error output??
However, I realised that I have not selected the TriBlade hardware. Unfortunately, some other things just cropped up that I was not expecting till tomorrow evening :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Here is the latest code (just ZiCog010_cpm_v1_0_rc4.spin and Zicog.spin changed)·but it still fails compilation. Run out of time to findout why as the label is valid. One problem I had is the compiler options were hard coded in the project file.
There are a few deliberate errors as I have not handled the sector packing yet. Maybe you may get a chance to look into it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Going off on a bit of a tangent here, heater asked in a PM about the source for BOOTGEN.COM.
I'm looking into how to get the boot ROM code working. Basically I'd like to have the boot code just read sectors sequentially off the SD for minimum boot times. Get rid of all that sector skewing that is in there now. This means eventually having to write a modified BOOTGEN so that TriBlade can rebuild CP/M and install it itself without SIMH. heater
I can't seem to find this. Just to brainstorm a bit about how to build boot tracks, the first thing to say is that it is complex. I've spent a lot of time inside the N8VEM system so might have some insights there. The confusing part is that programs need to be compiled so they sit in a different part of memory. So you might have an .ORG F800 at the beginning and so all the jump instructions work at that location, but it produces a binary image that might sit somewhere else in memory until it is needed. And, at least in CP/M, you can't just pad out bytes before and after as there isn't 64k to play with. So for the N8VEM, each file has a beginning and and end and so has a known length. eg dbgmon starts with .ORG F800 and finishes with .ORG FFFF. But even though it ends with FFFF, it is not FFFF bytes long. It is in fact FFFF-F800 bytes long, and starts at 0100H (as it is directly after the loader-m program that is o0 to FF. And then you have to be careful each program does not overwrite its allowed length. This is a real pain when writing custom bits of code, eg the LCD display driver in the N8VEM which now is part of CP/M!
Because of the overwrite problem, I found it easiest (as did Andrew Lynch) to have the minimum number of programs. It comes down to three, and it could be easier to even go for one single program. But even with 3, it gets confusing as the program cpm22-zz.asm is in fact a combination of the three bits of CPM, ie the CCP, BDOS and BIOOS.
Bill Beech over at the N8VEM group has been working for some time on using the individual files in CP/M and trying to keep the source files as 'pure' as possible. He would be the expert to ask on this problem.
They all have fixed lengths and then the DOS command copy /b joins them all together.
Now, if you want to do the compiling in CP/M it gets a bit more complex. You need ddt and you even need to compile and run programs to move code around before even doing the compiling. This is the dump of syscpm2.sub
; Create a bootable image on disk A: of CP/M with CCP
; Based on original Digital Research sources for CCP and BDOS
; Required sources are CFGCCP.LIB, MOVER.MAC, CCP.MAC, BDOS.MAC, CBIOSX.MAC
; Required programs: M80.COM, L80.COM, DDT.COM, BOOT.COM, BOOTGEN.COM
XSUB
; get correct configuration
PIP MEMCFG.LIB=CFGCCP.LIB
; create MOVER.COM
M80 =MOVER/M
L80 MOVER,MOVER/N/E
ERA MOVER.REL
; create CCP.COM
M80 =CCP/M
L80 CCP,CCP/N/E
ERA CCP.REL
; create BDOS.COM
M80 =BDOS/M
L80 BDOS,BDOS/N/E
ERA BDOS.REL
; create CBIOSX.COM
M80 =CBIOSX/M
L80 CBIOSX,CBIOSX/N/E
ERA CBIOSX.REL
; put pieces together
DDT
F100 5C00 0
IMOVER.COM
R0000
ICCP.COM
R0900
IBDOS.COM
R1100
ICBIOSX.COM
R1F00
G0
; create boot file
SAVE 44 CPMBOOT.COM
ERA MOVER.COM
ERA CCP.COM
ERA BDOS.COM
ERA CBIOSX.COM
ERA MEMCFG.LIB
; now perform a cold boot to get rid of XSUB
; this restores the original BIOS jump vector which is required by BOOTGEN
BOOT
; write boot file to reserved tracks, must be last command
BOOTGEN CPMBOOT.COM A:
The very last command is bootgen.com and that is the file we don't have the source for. But I'm not sure that matters. Just a few lines up is the command
SAVE 44 CPMBOOT.COM
This is saving a simple binary file which I think is 256*44 = 11264 bytes. That fits as that is 2C00 and at the beginning the code looks like this (which is the compiled MOVER.MAC) - copied from the binary version and viewed with ddtz (z80 opcodes).
A>ddtz cpmboot.com
DDT/Z [noparse][[/noparse]8101]
High = 2CFF Max = 2CFF
> l0100
0100 LD HL,0A00
0103 LD DE,DC00
0106 LD BC,2300
0109 LD A,(HL)
010A LD (DE),A
010B INC HL
010C INC DE
010D DEC BC
010E LD A,C
010F OR B
0110 JP NZ,0109
0113 JP F200
0116 NOP
0117 NOP
0118 NOP
0119 NOP
>>
Then it is padded out with zeros to 0A00. This code simply takes 2300H bytes and copies them from 0A00 to DC00 and then jumps to F200. (in Z80 opcodes a LDIR could do it with even less instructions).
So, I think all you have to do is build a binary file with a shortened version of syscpm2.sub that ends after SAVE command, and adds a new BOOTGEN which we write, which takes any .COM or binary file and copies it to the boot tracks, with no sector skewing and no fancy interleaving of alternate sectors. It could then copy itself to high memory and execute.
I guess that could be some spin code. It could look at the boot tracks and copy (say) 16k (11k+ a bit spare) into the first 16k of the zicog emulation and then jump to 0000 in the zicog. If the code was the code above, the first thing it then does is copies cpm into high memory and executes.
What do you need to make that? Well, I think it needs a tiny little program that moves a file to the boottrack, but in the format we want, ie straight binary. If you want to run all this within CP/M (which I think is entirely possible), then you need a little machine code program to do this.
One thing I'm not entirely sure about is whether CP/M can write a sector to track 0 of drive n? I'm guessing here, but every drive has parameters and those parameters are set in the drive parameter block and cp/m may try to send the data to somewhere different based on its parameter block data. To keep things very simple and very consistent with all drives, I wonder if we could just say that whatever drives we create, they all should have some data on the first track that is copied 1:1 into ram and then executed? Spin may be able to do that easier than anything else. eg, you have 16k worth of data at location x in the working ram and you want to move it to track 0 on the disk image. Maybe a special I/O call to trigger that. Then a cp/m program that takes any .com program and puts it into ram at a known location (?? at 0A00 but it doesn't really matter). And certainly it would be easy to write a vb6 program to do the same from a binary file on a pc hard drive.
I've been looking at some source code for programs similar to BOOTGEN on the walnut creek archive, eg SYSGEN but they seem to be customised for different hardware.
Sorry for the long post. It has taken so long, maybe in the meantime heater/cluso have already solved this one ?!
I would think that the easiest way is the way I currently boot ZiCog on the TriBlade (floppy boot). Heater gave me the "DSKBOOT.COM" file. I saved it as a seperate FAT16 file on the uSD. When the TriBlade boots..
It locates the start sector of all the drive files on the FAT16 uSD
It·locates "DSKBOOT_.ROM" (=DSKBOOT.COM) on the FAT16 uSD
Clears all 64KB (=Z80 RAM/ROM)
Places a jmp $FF00 at $0000
Loads 256 bytes from "DSKBOOT_.ROM" into $FF00
Starts ZiCog which runs $0000
This means that is is very easy to change the boot file "DSKBOOT_.ROM", or offer alternative boot files. I presume this is not something that should be changing regularly.
My understanding is that heater has actually done a similar thing (program)·for booting the hard drive.
However, heater just uses one long contiguous block of sectors on the uSD with no FAT16. The main reason is for space saving, but I am sure we can find a way around that. For instance, when the uSD is setup, we could run a seperate spin program that found the starting sector·of each drive file and the boot file under FAT16 and build a table in a fixed location·(maybe in a boot track of FAT16). That could be read in by ZiCog and we would be able to use the same uSD for the Demoboard and TriBlade and any others, maybe including N8VEM?
Now, I was thinking that it should be easy to run heaters Demoboard code on the TriBlade by not using the RAM and just changing the pins for the uSD. Maybe I will get a chance to have a quick look at this today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Dr_A: I have made a lot of progress on figuring out these things recently[noparse]:)[/noparse]
Re: Relocating code.
This turns out to be very easy, at least when using the Microsoft assembler M80. Take a look at the source for the SIMH boot loader ROM (DSKBOOT.MAC) for an example. That is written as a normal CP/M program with an "org 100h" at the beginning as if it were to be run from the TPA at 100H. But then it has the magic directive ".phase rom" where "rom" is previously equated to ff00h. After that all the jumps etc in the code are OK for when it is burned to ROM at address ff00h. BUT then it gets sneaky...The firs part of code in DSKBOOT runs from ROM and copies a second part to an address in RAM then jumps to it. The second part does the actual disk booting. To make all the references correct in the second part it is preceded with a directive ".phase cold" where "cold" is previously equated as the RAM address at which it actually run from.
This copying is unnecessary for us today but was done in the past as executing from RAM is faster than ROM.
This ".phase" directive is also used in CCP, BDOS and CBIOSX where the addresses to run from is taken from the common include file MEMCFG.LIB.
Re: Concatenating code.
Not so bad. "copy" will do it under Windows, "copy" or "cat" or "dd" will do it under Linux. With CP/M it is tricky because CP/M is dumb enough not to know the exact length of its files so that kind of concatenation is impossible in general.
Hence the use of DDT to load all the .COM files into RAM, move them to the correct addresses and then SAVE them.
Re: BOOTGEN.
I finally found the source of BOOTGEN on the appleiicpm.dsk (or was it app.dsk) that comes in the cpm2.zip package from SIMH. It is written in SPL and is very clear and simple. Basically it just takes the data from CPMBOOT.COM and writes it to the boot sectors of a disk. Sector writing starts at sector 8 and then has "skew" by writing even sectors followed by odd sectors.
(This is on top of any skew added by the actuall BIOS disk driver code). In addition it adds a "JP 100h at what will become address 0000H to get from reset to MOVER.COM
Not sure why the loading starts from sector 8 but there we go. All disks are treated the same by SIMH BOOTGEN by the way. Except the CBIOS skews the sectors for floppies but not hard disks.
So:
All we need to do is:
1) Build and save CP/M to CPMBOOT .COM as normal.
2) Write it out to the first sectors of a disk image. No skewing. Maybe starting at sector 8 like SIMH. This could be done with a simple modification to BOOTGEN or just using "dd" under Linux.
3) Change the boot loader to just read those sequential sectors off of disk.
4) Change the CBIOSX warm start loader similarly.
Using spin to load up is OK except for 4).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Blimey, I just stepped outside to mow the lawn and you have done all this! Well, that phase command is very cunning. Sounds like you have it all in hand. Ok, I'll see if I can get that ram chip in the mail in the next 24h
Heater: Can you please check the last code I posted compiles and runs. If so, then I can change the
disk.start(0)·· to··
disk.start(0,1,2,3)············ 'for DemoBoard
disk.start(9,28,8,14)········· 'for TriBlade (without using sram due to bus conflict - but sram may be in circuit)
and change the sdspiqasm start routine to accept the extra pin definitions.
Then we can run the TriBlade without sram so I can verify things work. For this, can you email me a zip of your sd file and how I put it onto the SD card with Windows (Vista) via an SD adapter or Windows (XP) via a USB adapter (not sure this one will work). If I have any dificulties I can always make it a file under FAT16 and find the start sector and 'plug' it into the code.
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Turns out that DSKBOOT reads the CPMBOOT.COM from the disk boot sectors and places it at 0000H in RAM then jumps to 0000H. The CPMBOOT contains MOVER.COM, CCP.COM, BDOS.COM and CBIOSX.COM concatenated and at offset 100H in the file. It also contains at offset 0000H a jump to 100H.
So basically:
1) CPMBOOT gets loaded to 0000H by DSKBOOT
2) DSKBOOT jumps to 0000H
3) There is a jump to 100H which is the MOVER
4) MOVER moves CCP,BDOS,CBIOSX to the correct location in RAM
5) MOVER then jumps to CBIOSX and we are up.
The ZIBOOT I made is simply the SIMH HDSKBOOT code modified to run at FF00. The original is loaded to and run from 5C00 by SIMH. Also the original HDSKBOOT looks into DSKBOOT at FF00 to determine which drive to boot from. So that needed changing with a coresponding change in the CBIOSX warm start routine.
So far ZIBOOT does not work. It manages to load something. Runs the loaded MOVER then runs enough of the CBIOSX to get the CP/M sign on message out. But it really looks like the CCP part did not get loaded so everything dies.
The worrying thing is that the CBIOSX warm start fails with the same symptoms which makes me think it may be our HD Spin driver that is faulty. But if so how come it can read/write DIMH HD images OK? I'll keep looking at it.
That's a sneaky idea about the FAT files on the DemoBoard. But I have to say creating my SDs under Linux with a simple "dd if=i.dsk of=/dev/sdf" command is easier than having to mount the SD as a floppy, format it, then copy the files to it and the unmount it. So I don't worry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1) Compiles and runs with PropDemoBoard and CPU_8080 defines.
2) At least compiles with TriBladeProp.
3) Changed loading of CCP, BDOS and CBIOSX to loading CPMBOOT.COM for demo board.
4) Changed sd_block to sd_block_number thoughout.
5) Renamed the sdspiqasm object instance from "disk" to "sd" for prop demo board as it is not a disk.
6) Put comments "Cluso something here perhaps" where some TriBlade effort may be needed [noparse]:)[/noparse]
Now I have to find what it was I did that was crashing BST ....
Edit: P.S. I commented all the #defines and was setting them in BST's project options.
Edit: P.P.S. Also contains i.dsk which is the SIMH I: disk image that I am using as my A: drive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
In theory. Just dump i.dsk onto to the SD. Find it's offset block number and use as drive A: as usual.
BUT so far I have failed to get it to work. Only boots far enough to run the BIOS and put up the CP/M sign on message. After that it jumps to the CCP but as far as I can tell by single stepping there is no code there only zeros.
This could be due to the limited RAM space on the DemoBoard. I could not get the old DSKBOOT to work either where as you have reported it working on TriBlade with 64K.
So if you get as far as I did I'll make a new i.dsk with a 64K CP/M build on it.
Otherwise its back to loading up CP/M into RAM prior to starting the emulator. But this time we only have to load CPMBOOT.COM into RAM at 0000 and run from 0000. Which is what rc_5 does when built for demo board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just added a spin function to read the A: disks boot records to RAM before starting.
Basically what ZIBOOT.MAC should (and will) do for boot up.
The 88 boot sectors are laid down sequentially (no skewing) from track 0 sector 8.
To do this I have made a new BOOTGEN.COM, included in the zip.
Here are spin files of rc5.5.
zicog_cpm.spin has one new function LoadZ80RAM called before CPU start.
zicog.spin has had the CPMBOOT.COM file statement removed and replaced with a BYTE array to reserve the boot loading RAM space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Heater: I think you may have a problem with not identifying the 24KB code space. IIRC, Spin will place the stack for the first cog (or something anyway) at the end of hub ram and you have not filled it to the end of the 24KB CPM space.
As I said previously, I have a mod for 5.5 (simple, so don't worry if you move on) that will allow us to run your code for the PropDemoBoard on the TriBlade without using the SRAM. Just have to do a simple program to find the offset for the disk file on the SD FAT16 card so we can code that into this code. At least then we can run your code also.
Here is how I am thinking of doing it. We can then both use the same routines.
Also Load another cog with a PASM routine (needs to be PASM so that it can initially reside within your 24KB CPM buffer)
This cog will talk to sdspiqasm to read the FAT16 and locate...
The boot code file (boot sectors if you like)
The 8 drive files for the hard disks (including the floppy and RamDisk emulated as hard drives)
will relay this information to the main spin program when done and terminate
The spin code will then boot CPM and will know the exact sector offsets for the boot file and drive files.
Your comments?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
This has changed a bit recently but the result was the same. The OBJ address of ram_z80_end is at 65K
BUT now you point it out I see this is a tad wrong. ram_z80_end is 10H bytes to low. Why ? Because that @padding does not account for the object base address.
Should be:
Not sure about this image file locating plan. Tell me again why we want to run in HUB RAM on the TriBlade. And if we do why not just use the raw (no FAT SD) anyway?
But I was thinking of a different technique. It would require zicog_cpm is always run from EEPROM.
1) User downloads zicog_cpm to EEPROM, at this point it fails when not finding any images.
2) User downloads to HUB RAM a little program that finds the drive image files in SD and POKES those SD block numbers into the zicog_cpm code EEPROM somewhere.
3) User then reboots the Prop and zicog_cpm now finds its images.
Where do the block numbers get saved in EEPROM. Well just define some MAGIC marker somewhere in DAT section which the finder program looks for and writes the results after it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater, a ram chip is winging its way from Australia to Finland as we speak. This should smooth out some of these bugs that are creeping in from different hardware.
So now, ZIBOOT works for cold booting up CP/M and CBIOSX has a warm boot routine that works.
Finally I can use PIP without it crashing on the warm start it does when it exits. Also the "BOOT" command works.
Here is a new ROM bootable disk image for use as drive A: (contains the new CBIOSX)
and the ZIBOOT.COM that loads it.
I'll try and get all this into a new complete package with updated instructions for building zicog's CP/M and all new CP/M sources/scripts when I have a moment.
I'll wait for a TriBlade operational version from you all first though then merge what little changes I have made to ZiCog for all this.
Edit: I'd also put the AUTOEXEC functionality back in.
Edit: Please, please, please, try not to go all around the code making non-functional formatting changes, moving comments around, lining up columns etc. I can't see the wood for the trees when there are a thousand lines of output of diff [noparse]:([/noparse]
Sadly because of Spins use of white space telling diff to ignore white space only changes is not a good idea.
We can do a formatting tidy up only release when everything is functional an all platforms.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I don't know about bugs but we have made major changes all around from CBIOS to BOOTGEN to to disk formats to ZiCog...I know it's quite a challenge to get it back into shape again.
Hopefully my other TriBlade parts are here soon as well.
What happened to Joda? Any comments/ideas form that direction?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
I think perhaps that 26K CP/M version only fits in the demo board if all the space saving options are turned on in BST.
Edit: Oh yes and it won't fit in the Prop Demo Board if CPU_Z80 is selected that takes a shed load more space than CPU_8080.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 9/7/2009 11:15:11 AM GMT
Yes still some things need fixing:
C:\Propeller\zicog92\Cluso 7 Sept 2009>bstc -p2 -d COM1 -e -Ox zicog010_demo_rr1
08.spin
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_rr108
Loading Object zicog
zicog(288,14) Error : Unresolved Symbol - ram_z80
BYTEMOVE (@ram_z80 + dma_address, hub_address, 128)
_____________^
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
However, I realised that I have not selected the TriBlade hardware. Unfortunately, some other things just cropped up that I was not expecting till tomorrow evening :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
There are a few deliberate errors as I have not handled the sector packing yet. Maybe you may get a chance to look into it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Had to uncomment defines TriBladeProp CPU_Z80
Found this in alu_neg_ovl: "wrbyte data_8, a_reg read_memory_byte"
should be " wrbyte data_8, a_reg"
No idea how that got there.
Had to remove all whites space from the end of "read_memory_byte_ret ret"
Never seen that before.
Zicog010_cpm_rr109.spin.
Uncomment the correct defines TriBladeProp and CPU_Z80
There should not be any problem with >32K as all that memory is taken for Z80 only when PropDemoBoard is defined.
Now to have a look what Cluso changed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I have to get my head around the buffering of the 4x1 sectors to fix the TriBlade code· 4 places I think?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I'm looking into how to get the boot ROM code working. Basically I'd like to have the boot code just read sectors sequentially off the SD for minimum boot times. Get rid of all that sector skewing that is in there now. This means eventually having to write a modified BOOTGEN so that TriBlade can rebuild CP/M and install it itself without SIMH.
heater
I can't seem to find this. Just to brainstorm a bit about how to build boot tracks, the first thing to say is that it is complex. I've spent a lot of time inside the N8VEM system so might have some insights there. The confusing part is that programs need to be compiled so they sit in a different part of memory. So you might have an .ORG F800 at the beginning and so all the jump instructions work at that location, but it produces a binary image that might sit somewhere else in memory until it is needed. And, at least in CP/M, you can't just pad out bytes before and after as there isn't 64k to play with. So for the N8VEM, each file has a beginning and and end and so has a known length. eg dbgmon starts with .ORG F800 and finishes with .ORG FFFF. But even though it ends with FFFF, it is not FFFF bytes long. It is in fact FFFF-F800 bytes long, and starts at 0100H (as it is directly after the loader-m program that is o0 to FF. And then you have to be careful each program does not overwrite its allowed length. This is a real pain when writing custom bits of code, eg the LCD display driver in the N8VEM which now is part of CP/M!
Because of the overwrite problem, I found it easiest (as did Andrew Lynch) to have the minimum number of programs. It comes down to three, and it could be easier to even go for one single program. But even with 3, it gets confusing as the program cpm22-zz.asm is in fact a combination of the three bits of CPM, ie the CCP, BDOS and BIOOS.
Bill Beech over at the N8VEM group has been working for some time on using the individual files in CP/M and trying to keep the source files as 'pure' as possible. He would be the expert to ask on this problem.
This is the build batch file for the N8VEM
They all have fixed lengths and then the DOS command copy /b joins them all together.
Now, if you want to do the compiling in CP/M it gets a bit more complex. You need ddt and you even need to compile and run programs to move code around before even doing the compiling. This is the dump of syscpm2.sub
The very last command is bootgen.com and that is the file we don't have the source for. But I'm not sure that matters. Just a few lines up is the command
SAVE 44 CPMBOOT.COM
This is saving a simple binary file which I think is 256*44 = 11264 bytes. That fits as that is 2C00 and at the beginning the code looks like this (which is the compiled MOVER.MAC) - copied from the binary version and viewed with ddtz (z80 opcodes).
Then it is padded out with zeros to 0A00. This code simply takes 2300H bytes and copies them from 0A00 to DC00 and then jumps to F200. (in Z80 opcodes a LDIR could do it with even less instructions).
So, I think all you have to do is build a binary file with a shortened version of syscpm2.sub that ends after SAVE command, and adds a new BOOTGEN which we write, which takes any .COM or binary file and copies it to the boot tracks, with no sector skewing and no fancy interleaving of alternate sectors. It could then copy itself to high memory and execute.
I guess that could be some spin code. It could look at the boot tracks and copy (say) 16k (11k+ a bit spare) into the first 16k of the zicog emulation and then jump to 0000 in the zicog. If the code was the code above, the first thing it then does is copies cpm into high memory and executes.
What do you need to make that? Well, I think it needs a tiny little program that moves a file to the boottrack, but in the format we want, ie straight binary. If you want to run all this within CP/M (which I think is entirely possible), then you need a little machine code program to do this.
One thing I'm not entirely sure about is whether CP/M can write a sector to track 0 of drive n? I'm guessing here, but every drive has parameters and those parameters are set in the drive parameter block and cp/m may try to send the data to somewhere different based on its parameter block data. To keep things very simple and very consistent with all drives, I wonder if we could just say that whatever drives we create, they all should have some data on the first track that is copied 1:1 into ram and then executed? Spin may be able to do that easier than anything else. eg, you have 16k worth of data at location x in the working ram and you want to move it to track 0 on the disk image. Maybe a special I/O call to trigger that. Then a cp/m program that takes any .com program and puts it into ram at a known location (?? at 0A00 but it doesn't really matter). And certainly it would be easy to write a vb6 program to do the same from a binary file on a pc hard drive.
I've been looking at some source code for programs similar to BOOTGEN on the walnut creek archive, eg SYSGEN but they seem to be customised for different hardware.
Sorry for the long post. It has taken so long, maybe in the meantime heater/cluso have already solved this one ?!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 9/8/2009 2:21:01 AM GMT
I would think that the easiest way is the way I currently boot ZiCog on the TriBlade (floppy boot). Heater gave me the "DSKBOOT.COM" file. I saved it as a seperate FAT16 file on the uSD. When the TriBlade boots..
This means that is is very easy to change the boot file "DSKBOOT_.ROM", or offer alternative boot files. I presume this is not something that should be changing regularly.
My understanding is that heater has actually done a similar thing (program)·for booting the hard drive.
However, heater just uses one long contiguous block of sectors on the uSD with no FAT16. The main reason is for space saving, but I am sure we can find a way around that. For instance, when the uSD is setup, we could run a seperate spin program that found the starting sector·of each drive file and the boot file under FAT16 and build a table in a fixed location·(maybe in a boot track of FAT16). That could be read in by ZiCog and we would be able to use the same uSD for the Demoboard and TriBlade and any others, maybe including N8VEM?
Now, I was thinking that it should be easy to run heaters Demoboard code on the TriBlade by not using the RAM and just changing the pins for the uSD. Maybe I will get a chance to have a quick look at this today.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Re: Relocating code.
This turns out to be very easy, at least when using the Microsoft assembler M80. Take a look at the source for the SIMH boot loader ROM (DSKBOOT.MAC) for an example. That is written as a normal CP/M program with an "org 100h" at the beginning as if it were to be run from the TPA at 100H. But then it has the magic directive ".phase rom" where "rom" is previously equated to ff00h. After that all the jumps etc in the code are OK for when it is burned to ROM at address ff00h. BUT then it gets sneaky...The firs part of code in DSKBOOT runs from ROM and copies a second part to an address in RAM then jumps to it. The second part does the actual disk booting. To make all the references correct in the second part it is preceded with a directive ".phase cold" where "cold" is previously equated as the RAM address at which it actually run from.
This copying is unnecessary for us today but was done in the past as executing from RAM is faster than ROM.
This ".phase" directive is also used in CCP, BDOS and CBIOSX where the addresses to run from is taken from the common include file MEMCFG.LIB.
Re: Concatenating code.
Not so bad. "copy" will do it under Windows, "copy" or "cat" or "dd" will do it under Linux. With CP/M it is tricky because CP/M is dumb enough not to know the exact length of its files so that kind of concatenation is impossible in general.
Hence the use of DDT to load all the .COM files into RAM, move them to the correct addresses and then SAVE them.
Re: BOOTGEN.
I finally found the source of BOOTGEN on the appleiicpm.dsk (or was it app.dsk) that comes in the cpm2.zip package from SIMH. It is written in SPL and is very clear and simple. Basically it just takes the data from CPMBOOT.COM and writes it to the boot sectors of a disk. Sector writing starts at sector 8 and then has "skew" by writing even sectors followed by odd sectors.
(This is on top of any skew added by the actuall BIOS disk driver code). In addition it adds a "JP 100h at what will become address 0000H to get from reset to MOVER.COM
Not sure why the loading starts from sector 8 but there we go. All disks are treated the same by SIMH BOOTGEN by the way. Except the CBIOS skews the sectors for floppies but not hard disks.
So:
All we need to do is:
1) Build and save CP/M to CPMBOOT .COM as normal.
2) Write it out to the first sectors of a disk image. No skewing. Maybe starting at sector 8 like SIMH. This could be done with a simple modification to BOOTGEN or just using "dd" under Linux.
3) Change the boot loader to just read those sequential sectors off of disk.
4) Change the CBIOSX warm start loader similarly.
Using spin to load up is OK except for 4).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
disk.start(0)·· to··
disk.start(0,1,2,3)············ 'for DemoBoard
disk.start(9,28,8,14)········· 'for TriBlade (without using sram due to bus conflict - but sram may be in circuit)
and change the sdspiqasm start routine to accept the extra pin definitions.
Then we can run the TriBlade without sram so I can verify things work. For this, can you email me a zip of your sd file and how I put it onto the SD card with Windows (Vista) via an SD adapter or Windows (XP) via a USB adapter (not sure this one will work). If I have any dificulties I can always make it a file under FAT16 and find the start sector and 'plug' it into the code.
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Turns out that DSKBOOT reads the CPMBOOT.COM from the disk boot sectors and places it at 0000H in RAM then jumps to 0000H. The CPMBOOT contains MOVER.COM, CCP.COM, BDOS.COM and CBIOSX.COM concatenated and at offset 100H in the file. It also contains at offset 0000H a jump to 100H.
So basically:
1) CPMBOOT gets loaded to 0000H by DSKBOOT
2) DSKBOOT jumps to 0000H
3) There is a jump to 100H which is the MOVER
4) MOVER moves CCP,BDOS,CBIOSX to the correct location in RAM
5) MOVER then jumps to CBIOSX and we are up.
The ZIBOOT I made is simply the SIMH HDSKBOOT code modified to run at FF00. The original is loaded to and run from 5C00 by SIMH. Also the original HDSKBOOT looks into DSKBOOT at FF00 to determine which drive to boot from. So that needed changing with a coresponding change in the CBIOSX warm start routine.
So far ZIBOOT does not work. It manages to load something. Runs the loaded MOVER then runs enough of the CBIOSX to get the CP/M sign on message out. But it really looks like the CCP part did not get loaded so everything dies.
The worrying thing is that the CBIOSX warm start fails with the same symptoms which makes me think it may be our HD Spin driver that is faulty. But if so how come it can read/write DIMH HD images OK? I'll keep looking at it.
That's a sneaky idea about the FAT files on the DemoBoard. But I have to say creating my SDs under Linux with a simple "dd if=i.dsk of=/dev/sdf" command is easier than having to mount the SD as a floppy, format it, then copy the files to it and the unmount it. So I don't worry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Uses Cluso's last posted files plus:
1) Compiles and runs with PropDemoBoard and CPU_8080 defines.
2) At least compiles with TriBladeProp.
3) Changed loading of CCP, BDOS and CBIOSX to loading CPMBOOT.COM for demo board.
4) Changed sd_block to sd_block_number thoughout.
5) Renamed the sdspiqasm object instance from "disk" to "sd" for prop demo board as it is not a disk.
6) Put comments "Cluso something here perhaps" where some TriBlade effort may be needed [noparse]:)[/noparse]
Now I have to find what it was I did that was crashing BST ....
Edit: P.S. I commented all the #defines and was setting them in BST's project options.
Edit: P.P.S. Also contains i.dsk which is the SIMH I: disk image that I am using as my A: drive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 9/8/2009 7:45:12 AM GMT
So if I just copy i.dsk and adjust the sector number from 0 to this offset, should ZiCog then boot?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
BUT so far I have failed to get it to work. Only boots far enough to run the BIOS and put up the CP/M sign on message. After that it jumps to the CCP but as far as I can tell by single stepping there is no code there only zeros.
This could be due to the limited RAM space on the DemoBoard. I could not get the old DSKBOOT to work either where as you have reported it working on TriBlade with 64K.
So if you get as far as I did I'll make a new i.dsk with a 64K CP/M build on it.
Otherwise its back to loading up CP/M into RAM prior to starting the emulator. But this time we only have to load CPMBOOT.COM into RAM at 0000 and run from 0000. Which is what rc_5 does when built for demo board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just added a spin function to read the A: disks boot records to RAM before starting.
Basically what ZIBOOT.MAC should (and will) do for boot up.
The 88 boot sectors are laid down sequentially (no skewing) from track 0 sector 8.
To do this I have made a new BOOTGEN.COM, included in the zip.
Here are spin files of rc5.5.
zicog_cpm.spin has one new function LoadZ80RAM called before CPU start.
zicog.spin has had the CPMBOOT.COM file statement removed and replaced with a BYTE array to reserve the boot loading RAM space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Code to follow when I have warm boot working as well.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
As I said previously, I have a mod for 5.5 (simple, so don't worry if you move on) that will allow us to run your code for the PropDemoBoard on the TriBlade without using the SRAM. Just have to do a simple program to find the offset for the disk file on the SD FAT16 card so we can code that into this code. At least then we can run your code also.
Here is how I am thinking of doing it. We can then both use the same routines.
Your comments?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I have tried to fill 25K of DAT space with either emulator PASM code or Z80 RAM.
So the DAT area starts with some Z80 RAM space
ram_z80 BYTE 0[noparse][[/noparse]22 * 512] 'Reserve space for boot loading by SpinThen we get the emulator COG code
DAT org 0 entry ......cog instructions hereThen we get the end of Z80 RAM padded to 25K
padding BYTE 0[noparse][[/noparse](msize * 1024) - @padding] ram_z80_endThis has changed a bit recently but the result was the same. The OBJ address of ram_z80_end is at 65K
BUT now you point it out I see this is a tad wrong. ram_z80_end is 10H bytes to low. Why ? Because that @padding does not account for the object base address.
Should be:
BYTE 0[noparse][[/noparse](msize * 1024) - @padding + @ram_z80]▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 9/9/2009 4:56:09 AM GMT
But I was thinking of a different technique. It would require zicog_cpm is always run from EEPROM.
1) User downloads zicog_cpm to EEPROM, at this point it fails when not finding any images.
2) User downloads to HUB RAM a little program that finds the drive image files in SD and POKES those SD block numbers into the zicog_cpm code EEPROM somewhere.
3) User then reboots the Prop and zicog_cpm now finds its images.
Where do the block numbers get saved in EEPROM. Well just define some MAGIC marker somewhere in DAT section which the finder program looks for and writes the results after it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Finally I can use PIP without it crashing on the warm start it does when it exits. Also the "BOOT" command works.
Here is a new ROM bootable disk image for use as drive A: (contains the new CBIOSX)
and the ZIBOOT.COM that loads it.
I'll try and get all this into a new complete package with updated instructions for building zicog's CP/M and all new CP/M sources/scripts when I have a moment.
I'll wait for a TriBlade operational version from you all first though then merge what little changes I have made to ZiCog for all this.
Edit: I'd also put the AUTOEXEC functionality back in.
Edit: Please, please, please, try not to go all around the code making non-functional formatting changes, moving comments around, lining up columns etc. I can't see the wood for the trees when there are a thousand lines of output of diff [noparse]:([/noparse]
Sadly because of Spins use of white space telling diff to ignore white space only changes is not a good idea.
We can do a formatting tidy up only release when everything is functional an all platforms.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 9/9/2009 6:14:17 AM GMT
I don't know about bugs but we have made major changes all around from CBIOS to BOOTGEN to to disk formats to ZiCog...I know it's quite a challenge to get it back into shape again.
Hopefully my other TriBlade parts are here soon as well.
What happened to Joda? Any comments/ideas form that direction?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build