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 ]

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/7/2009 7:21 PM (GMT -8)    Quote This PostAlert An Admin About This Post.

Thinking about your post James.

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:
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/7/2009 9:10 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Dr_A: I have made a lot of progress on figuring out these things recently:)

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.

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/7/2009 9:26 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
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


www.smarthome.viviti.com/build

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/7/2009 9:40 PM (GMT -8)    Quote This PostAlert An Admin About This Post.

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 cool


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/7/2009 9:43 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Cluso:

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.

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/7/2009 9:45 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Cluso, give me an hour to get that packaged.


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/7/2009 10:25 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
That's odd. Twice now crashed BST trying to compile Cluso's latest files !!


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/7/2009 10:55 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Not had that happen, but I cannot compile the code as TriBlade yet :-(


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/7/2009 11:35 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Here is zicog_cpm_1_0_rc_5

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 :)

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



File Attachment :
zicog_cpm_1_0_rc_5.zip   419KB (application/x-zip-compressed)
This file has been downloaded 13 time(s).
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/8/2009 12:09 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Thanks heater.

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:
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/8/2009 12:28 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
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.

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/8/2009 7:24 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
ZiCog can now start from boot sectors on drive A:

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.



File Attachment :
zicog_cpm_1_0_rc_5.5.zip   416KB (application/x-zip-compressed)
This file has been downloaded 15 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/8/2009 11:00 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Yeeesss...zicog_cpm is now booting from the ZIBOOT bootloader in ROM !

Code to follow when I have warm boot working as well.


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/8/2009 2:11 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Great news heater. Well done :-) I haven't had a chance to look further yet, but this is a fantastic advance.


Links to other interesting threads:
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/8/2009 5:54 PM (GMT -8)    Quote This PostAlert An Admin About This Post.

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:
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/8/2009 8:44 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Thanks Cluso, you have pointed out a bug, but not the one you think:)

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[22 * 512]                            'Reserve space for boot loading by Spin


Then we get the emulator COG code


DAT
                        org     0
entry ......cog instructions here


Then we get the end of Z80 RAM padded to 25K

padding
              BYTE 0[(msize * 1024) - @padding]
ram_z80_end


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:


              BYTE 0[(msize * 1024) - @padding + @ram_z80]


For me, the past is not over yet.

Post Edited (heater) : 9/9/2009 4:56:09 AM 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/8/2009 9:12 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
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.

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/8/2009 9:50 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
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.


www.smarthome.viviti.com/build

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/8/2009 9:59 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
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 :(

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



File Attachment :
ZIBOOT.COM.zip   0KB (application/x-zip-compressed)
This file has been downloaded 11 time(s).

File Attachment :
a_ziboot.dsk.zip   344KB (application/x-zip-compressed)
This file has been downloaded 11 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/8/2009 10:16 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Dr_A, thank you, that's great.

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.

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/8/2009 10:32 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Yoda? Dissappeared he has.


www.smarthome.viviti.com/build

Back to Top
 

Hanno
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailablePrivate Messaging Not AvailableAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined May 2007
Total Posts : 447
 
   Posted 9/8/2009 11:30 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Great work heater!
Truly inspiring.
Hanno


Download a free trial of ViewPort- the premier visual debugger for the Propeller
Includes full debugger, simulated instruments, fuzzy logic, and OpenCV for computer vision. Now a Parallax Product!

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/8/2009 11:34 PM (GMT -8)    Quote This PostAlert An Admin About This Post.
Heater:

My apologies for the code tidyup. I thought you were busy with other things when I did it, so thought you would take my additions. Anyway, it was easy for me to insert your mods.

I like your idea of plugging the base address(es) of the SD card into eeprom. There could be another way by using one of the reserved boot sectors to store the offsets. That way, we can change SD cards. It is easy to check for "FAT16". This can happen in the background for now anyway.

Why do I want to get the PropDemo version running on the TriBlade?
Currently I haven't added the code to do the blocking, so at least I thought I could get the latest code running again so I can test out your latest mods.


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/9/2009 12:32 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Gosh Hanno, coming from you I take that as a very great compliment. Probably more than is deserved.

Cluso, no apologies needed, it was just unlucky that it coincided with the huge code turmoil going on at this end.

The boot sector idea sounds solid. I just thought it would be nice to to have to introduce any more sneaky and "transient" code into zicog.spin. It's long, rambling and complicated enough already. Didn't much like to put the z80_ram in there either but at least it is tightly bound to the CPU workings and enable me simplify the parameter list passed into it most of which is not needed for TriBlade anyway.

Good point about having a working version using HUB RAM to build from.

I was thinking though. Presumably it's simple enough for you to get the thing compiled for TriBlade, as I have done, and up to the point where external RAM access is at least working.
Then if you have ZIBOOT loaded into external RAM at the right place you can single step through it. Very soon comes a disk sector read. So there we have built in blocking disk access test, just need to print out the first few sectors read in and compare to the hexdump of the disk.

And so....I should release a boot from disk version package ASAP.


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/9/2009 2:58 AM (GMT -8)    Quote This PostAlert An Admin About This Post.
Heater: Would you like to post your latest 2 Zicogxxx.spin files with the above fixes?

And the instructions please (windows vista) to create the SD disk with just the a_ziboot.dsk on it (not FAT16) so I can run your code.


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 10:59 PM (GMT -8)
There are a total of 393,737 posts in 55,521 threads.
In the last 3 days there were 82 new threads and 702 reply posts. View Active Threads
Who's Online
This forum has 17687 registered members. Please welcome our newest member, mark09.
56 Guest(s), 6 Registered Member(s) are currently online.  Details
Peter Verkaik, BradC, Harley, Chris Savage (Parallax), Rich_W8VK, potatohead