I have been up and running for about 2 weeks on the TriBlade. I have a vt100 emulator running on blade 1 as a terminal. Have you modified the stock bios for the addition of the hard drives? I am interested in working on packing the data to into the SD sectors. For reads this should give some improvements and it will be more compatible with the propIO board I am developing for the N8VEM. I am thinking of using one of the reserved bits on the disk controller to communicate information on the writes. BDOS is supposed to indicate when a write is a directory update which must be written out immediately other wise lazy writes can be employed.
Sorry I have been offline for two days [noparse]:([/noparse] So much to catch up on.
Yoda: I have a VB6 program that does the packing from the downloaded CPM files into windows files which I then copy using windows to the SD card - I use FAT16 to store the files (1 per hard drive). email me if you would like a copy (no hacked together)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I've downloaded but not got it running as yet. Spin and Pasm are still mysterious languages to me. But I can reverse engineer the code from Z80 opcodes, which I do understand! Also, there is something great about being on the steep part of the learning curve, where suddenly big concepts come together. This is also the time when lots of questions arise, so:
I see two flavours in the code - one for running on the triblade and one for talking to a terminal on a PC. I presume that means that one version is talking via high speed to blade 1, and the other is talking via the programming cable back to the PC?
There is a lot of mention about tv.text in the code - is there equivalent code for driving vga? Or if one wanted vga, would this be done in blade 1?
Is the zicog still running in just 20k?
Could someone please explain 'homespun' - is this some sort of different compiler?
How are things going with using FAT on the SD card - is it now at the stage of putting .dsk disk images in FAT on the sd card, in any order, and the code can find them?
Do bios calls in cp/m (and/or raw OUT statements) have any real world effect? Eg if you send an OUT to a certain address (0 to 255) on a real board, you can put 8 bits into a latch, or send a byte out of a uart. I'm a bit confused about where bytes go - eg with one version the byte goes to a tv screen but in the other version it goes to the serial port back to the pc, and ?? in another version it goes via a high speed serial link to blade 1. I'm trying to work out how this could fit in with CP/M where you had several devices, like a punch tape reader with standard BIOS calls. It could lead to a standard way of running several serial ports all at once, just make one the console, one the puch tape, one the list device etc.
I'll keep looking through the code - it is all most fascinating.
I had Blade #1 & #2 talking a while back. At the moment, because I am still in development mode, I am back to using the PC to simulate the terminal using PC_text and PC_keyboard and PropTerminal.
VGA would be substitutable for TV - may be a minor change to the call (TV.out and FDX.tx are the same). TV is just used as the object name so we can change PC or terminal without changing the code, just the object.
I have a full 64KB Ram (and am making 256KB available·using bank switching in CPM3) so my code uses the whole lot for CPM whereas heater is restricted to 19K/20K on non-TriBladeProp boards.
We also have different methods for the disks (floppy and hard disks). I am using separate files for each drive (8 floppies at 1MB) and am currently adding 1-4 hard drives at 8MB each. Each file MUST be contiguous within the file and is stored and located under FAT16 and is only using the first 128 bytes of each 512 byte SD sector. Heater is not using FAT16 and all drives are one long contiguous data block on the SD card. I copy my files onto the SD on the PC using windows file copy. I start booting PropDos/PropCmd so I can run any Prop binary stored on the disk which happens to include ZiCog.
Homespun is the compiler (spin & pasm) written by mpark (Michael). It has extensions to use #define which gives heater and I the ability to select various option when compiling (such as hardware). BradC has modified his bstc compiler to also support #define. PropTool no longer compiles our code unless you remove all the #define statements and the associated code.
Heater is tapping the various I/O statements and substituting them in spin. It will be possible (but not yet) to communicate to multiple ports on Blade #1.
Currently I am in the middle of getting the hard disks running. The I need to find out why I have to enter characters twice to get CPM3 working e.g. DDIIRR to do a DIR. No work done in the last 2 days (driving Brisbane - Sydney)
Hope this answers your questions.
I have seen the memory discussions on the other threads but no time to comment yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Good to see some successes out there. So let's continue.
Yoda: I am using the stock CP/M 2 BIOS from the SIMH Altair Z80 project. Or at least I am now that Peter Schorn has include one of my bug fixes in the SIMH CBIOSX.COM, 3rd May 2009 release.
I'd like to keep it that way as it is a good working reference. I don't need to be debugging a Z80 emulation and hardware emulation AND a custom BIOS all at the same time. Also means it's easy to move disk images between the two emulations.
The only change being the definitions of memory size and number of hard disks in an include file CCPCFG.LIB. I specify 23K RAM for the Prop Demo Board HUB RAM available and only 1 HD as each disk in use eats more RAM space. On the TriBlade the stock CP/M 2 is used but configured for 64K. I don't do any packing of sectors into SD BLOCKS., just one sector one block. I was having a hard enough time getting it working without packing [noparse]:)[/noparse] Then I thought if I do packing I need to be sure I read a block, update the relevant sector then write the block. Awful slow unless I remember I've already have a block in the disk buff from the last read/write. A cache. I got lazy so if you or anyone would like to try packing I'd be very happy.
For CP/M 3 I do modify the BIOS3.COM a little. Nothing to do with disks. But to simplify and speed up bank switched memory on the TriBlade.
I've never come across this "lazy writes" thing you describe. Is that in CP/M 2 BDOS? Where?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater what do you use to compile it?
I tried BST and homespun
BST doesn't like the #else
and homespun doesn't carry the #defines from zicog_demo.spin into zicog.spin, as it was erroring out saying no HW defined then no CPU when I put the hw define in zicog.spin also.
Dr_A. Yes there are two main flavours built from the same code. One for the Prop Demo Board and one for the TriBlade. We are using #ifdef, #elseifdef, etc compiler directives (as in C) to choose which parts of the code get compiled in for which platform. So you must have some #defines to select what you want. There are also some "sub flavours" depending if you want bank switched memory or a heartbeat LED etc. The defines are all described at the top of zicog_demo.spin.
Currently these # directives are only supported by mpark's HomeSpun and BradC's BST compilers. For HomeSpun you have to use the #defines in the Spin code. For the latest BST you can put defines in the project options.
TV.bla bla should probably be renamed (console.bla for example) you will see that you can use TV or VGA or PC.. or whatever object has the same interface to get chars onto a display somewhere. I have had a build running with a TV and my first efforts used a 2 line LCD!
The last release uses 23K of HUB RAM for CP/M on the DemoBoard. No doubt Cluso is fixing it up to use 64K on TriBlade, which he has already got working in previous releases, and to get the hard drives working there.
The DemoBoard build does not use FAT. Not enough space for the code. TriBlade does. It seems to work fine.
All IO instructions are passed from the PASM Z80 emulator to the SPIN peripheral emulation. Here the port numbers and data bytes are interpreted and the appropriate action taken. Console out, disk operations etc. You will see in the code a few lines commented out where I used to take data written to a certain IO address and put it straight to the LEDS of the Demo Board. So it very easy to add emulation of more peripheral devices. What they would do is another matter. The TriBlade has no free pins so everything has to be multiplexed through the serial link eventually. On DemoBoard you have some pins free for more serial ports etc. But then it is running out of space to put more code !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I use BST 018-Pre5 on Linux with the defines placed in the Project dialog. Or I can compile with HomeSpun if I put the defines into the spin code.
On Windows the latest BST release I tried would only compile with the defines in the code. The project settings did not work and everything was going to hell.
I'm just about to try again with the latest BST for Windows.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If there is no SD card it should run up to the A> prompt (after a bunch of disk read error messages)
If there is an SD card it will need a raw CPM disk image (or more) putting onto it. The demo board does not use FAT so that's a bit tricky.
My old method was to take a cpm2.dsk file from the SIMH AlatirZ80 site and use PropTerminal to down load it to the Propeller using cpm2sd.spin running on the prop. This takes about 5 mins over the serial link.
My new method is to use the python script mk_zicog_image.py which takes 8 floppy images and one hard disk image (all available from SIMH) and massages them into a 64Mbyte image file. I then put that image file onto SD card via an SD reader/writer under Linux using the "dd" command. E.g.
dd if=zicog.img of=/dev/sdf
The python script can be modified for different input disk images and can be run under Windows.
I have yet to find a Windows equivalent of "dd" to put raw data on a card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm actually going to get it on the Hybrid [noparse]:)[/noparse] as it has SD
and will also have the ability to add the HX512 to get the full 64K eventually [noparse]:)[/noparse]
Heater:
Here is v0.09 with·my updates. Note: Hard Disk is still wip.·I have added the extra #defines to ZiCog009_rr090.spin so that homespun v024 compiles correctly
Baggers:
I am using FAT16 SD files for the disks. It is a much easier method to get files onto SD but uses more hub space so you must have external ram. All files are posted on the TriBlade thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I think you are still putting 1 CPM sector into 1 SD sector. What I am proposing is to put 4 CPM sectors into 1 SD sector. I have written programs in python to manipulate the disk images so I am ok there. If you want to send me a copy of 0.09 I can try to give you a hand on the hard disk stuff - have read through Heater's code and have a pretty good understanding of it.
@Heater
The lazy write is generally in the BIOS, but should be pretty easy to implement in the disk code in Cluso's or your code. There is a bit set on one of the BDOS calls to tell you that a write is to a directory entry. You must write them out immediately. On other writes you can cache until you have a physical sectors worth and then do the write. Yes there is some logic to remember what sector you have in the buffer and you may have to do a read before write in some instances to do the lazy write. I think that all can be contained in the SD interface code (if I am lucky).
@Dr A
Send me a note and I can send you a modified PockeTerm code for Blade #1 and code changes to Cluso's last publish for them to work together - very minor changes. I would suggest you make the mod for cross over of the lines between the blades (2 cut traces , 2 wires). I think the change is in the TriBlade thread about a week ago.
@Yoda
Yes I am only using 1 cpm sector (128 bytes not 137) per SD sector, although I packed the SRAM disk up with 4 x 128 byte sectors per SD sector.
I posted the v0.09 code a few hours ago. I am just about to try reading the hard disk. I will let you know if I get it working.
Lazy write: There is more complexities to this because in my TriBlade the ram bus is shared with the SD bus, so you have to be careful not to permit overlapped I/O due to bus conflicts. The reason we are wasting space on the SD card is to simplify the code... 1x128 byte sector = 1 SD sector. No need to worry about where to place it (offset). There is plenty of room in a 2GB SD card so why worry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I will take a look at the code. I understand what you are saying. When we get to CPM3 you can have 512MB hard drives so the wasted space will become a problem. You would only get one drive on SD and nothing else.
@Yoda:
oops Sorry, I seemed to have not posted it where I should have. Posted now (a few posts back) where it should hae been.
When we get CPM3 running I gather we can have 512 byte sectors anyway so that will solve the problem. What files do you think will be that big ??? this is not windoze bloatware
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I was suggesting that if you did not have 512 byte sectors in CPM3 (I was not sure), in the current strategy of a 128 byte sector in a 512 byte SD sector, then a 512MB hard drive would be 2GB (4 x 512MB). Then there would be no more room on a 2GB SD card
Yes, but do we require a 512MB hard disk??? Currently all my files on the sd card are 32MB (even for the 1MB floppies) and I have 20 odd already because of variations. I haven't bothered to reformat my SD yet to remove the old useless files/drives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
True, but I want to do because we can Also when you start putting the compilers and other tools together like I want it is easier to keep in one disk in different user areas then hunting down drive letters. I am one of those pack rats and never have enough disk space (I think I am in excess of 15TB already in my house)
We can change the sector size (for CP/M 3) with a simple change to the to the Disk Parameter Blocks.
The DPRs for hard disks are defined in the Spin code and fed into the BIOS when it logs a new drive.
In the last ZiCog I included a DPB for a 730K floppy which can be used for a RAM disk. I borrowed that DPR from the SIMH AltairZ80 source code.
Any CP/M experts out there who could dream up a nice DPB for 512 byte sectors and "huge" disk capacity.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Hi heater, et al
I just had a couple of hours today and read most of the thread. I downloaded zilog_v0.6-tst.zip files and
it seems to load and run just fine. (very impressive). I am using a RPM board and PST (Prop Simple Terminal). I used ED to save a five line text file. CTRL-Z to return to Command mode and·E command to return, but it hangs before returning to the prompt. I guess thats just because we ran out of RAM. Ed wants a 5K buffer
Restarting Zilog and cmp2 the text was saved Ok and was able to view the five lines of text (type a:newfile)
Yikes, looks like I will have to wait until we get back to Australia in August, meanwhile there are a couple of other unfinished Propjects !
Anyone know how to config ED to 2K instead of 5k ?
BTW I used PST because I could not get PropTerminal to send CTRL key strokes
Ron
Post Edited (Ron Sutcliffe) : 5/17/2009 8:59:24 AM GMT
I have a Triblade blade #2 soldered up. I can recognise the prop and program the propeller with some demo code.
A few quick questions and help would be most appreciated:
1) Is there a link to the latest software? The version I have is from a few months ago now and might be obsolete. The spin file from further up this page won't compile (either a 'missing top file' error or a 'missing ,' error after the #define CPU_8080). I think I'm missing some files...
2) FAT, not FAT32 format on the SD card, right? Clean format then put a SIMH disk image on the card?
3) I'm going to start simple and just talk to this with text for the moment. So it downloads via pin 39/40 on the Prop. Presumably those pins can then be used for CP/M to talk back to the PC and you could do that with any terminal program. Is there a version of zicog set up to do this (I think there was on some previous posts). And is there a 'terminal' within the Prop IDE, to save shutting down the IDE and starting up hyperterminal? (no problem if there isn't).
4) Can I use a 574 instead of a 573? I'm pretty sure I can as both will latch on the +ve edge of the clock pulse.
5) Is there a link to a 'preferred' disk image. Or will any old SIMH disk image do?
6) and, last but not least, how do I get the sd card into the socket? I hope I haven't soldered something wrong, because there is a RAM chip in the way! The other end of the ram chip lines up with the prop, but even with the two spare holes at the pin 1 end it still needs a couple of mm extra to get the sd card in.
I'm eagerly looking forward to seeing that A> prompt!
Post Edited (Dr_Acula (James Moxham)) : 7/31/2009 3:25:49 AM GMT
2) FAT16 preferrably 32KB clusters. Then copy the files so each is contiguous. (see above link)
3) Yes, Yes and not quite. The terminal program is not actually within the Prop IDE, it is another program. There are 2 terminal programs, PropTerminal and PST (Parallax Serial Terminal). PropTerminal is best for this. I think you get it from the OBEX. Don't waste too much time looking as I can email it if you cannot find it. When the Prop IDE loses focus the program releases the com port (usb in our case). So after downloading, click on the terminal program (PST requires you to also click on the "enable" button). Both PropTerminal and PST release the com port when they lose focus. One other thing, you will require either the Homespun or bst compiler. I was using homespun when I published the code, so use that for now. After saving any changes made to the code in PropTool (Prop IDE), SAVE the code, switch to the compile window (a DOS window and compile). Once again I·should send you the batch files to make this easy. Then use Prop Tool to download the code. This is a bit messy at first. BST has an IDE for all of this, I just haven't had time to use it since Brad added the conditional compile functions.
4) Sorry, no you cannot use a '574. The '573 is a transparent latch meaning that while LE is high data passed through, and latches on the falling edge of LE. You require a 74HC573, 74AHC573. 74LVC573 is also usable.
5) I have posted disk images and instructions (link above). I use VB to convert the SIMH image directly from 137 byte sectors to 128 byte sectors per 512 byte SD sector. That is, I remove the extra (unused) 9 bytes.
6) OOPS - sorry·you have soldered the uSD socket in 180 degrees rotated. The card plugs in from the edge of the pcb.
Note there is a mod to wire -OE from prop to sram. See the TriBlade thead (link above)
Waiting anxiously for another A> prompt
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Thanks for that. Looks like I need to pick up a latch chip. Good excuse to skive off during my son's soccer match tomorrow am...
I'll get homespun then.
Some pre-processing needed on the simh images? Maybe I could put that into my vb.net IDE (which includes a terminal as well). And shell out to homespun so it is all in one place??
Re the sd socket, mine looks like the photo http://bluemagic.biz/clusodocs/tribladeprop_a1d.jpg Maybe it is right? Perhaps it isn't going in because the solder blobs are a bit high on the surface mount. I'll double check when I get home from work. All very exciting!
Post Edited (Dr_Acula (James Moxham)) : 7/31/2009 4:52:06 AM GMT
Dr_A: I can send you the VB code to include the pre-processing if you would like, including the code that generates a blank 32MB file. I will be off-air tomorow but you can try my mobile if need be (flying late afternoon to Sydney).
BTW: I just checked·and zicog009_rr090.spin is the latest code but may not include everything meaning you may also require the code referred to in my post above (see this thread on this page above for rr090)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
In response to your query: I have Zicog running on a TriBladeProp and a breadboard setup.
I have been up and running for about 2 weeks on the TriBlade. I have a vt100 emulator running on blade 1 as a terminal. Have you modified the stock bios for the addition of the hard drives? I am interested in working on packing the data to into the SD sectors. For reads this should give some improvements and it will be more compatible with the propIO board I am developing for the N8VEM. I am thinking of using one of the reserved bits on the disk controller to communicate information on the writes. BDOS is supposed to indicate when a write is a directory update which must be written out immediately other wise lazy writes can be employed.
Dave
Yoda: I have a VB6 program that does the packing from the downloaded CPM files into windows files which I then copy using windows to the SD card - I use FAT16 to store the files (1 per hard drive). email me if you would like a copy (no hacked together)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I see two flavours in the code - one for running on the triblade and one for talking to a terminal on a PC. I presume that means that one version is talking via high speed to blade 1, and the other is talking via the programming cable back to the PC?
There is a lot of mention about tv.text in the code - is there equivalent code for driving vga? Or if one wanted vga, would this be done in blade 1?
Is the zicog still running in just 20k?
Could someone please explain 'homespun' - is this some sort of different compiler?
How are things going with using FAT on the SD card - is it now at the stage of putting .dsk disk images in FAT on the sd card, in any order, and the code can find them?
Do bios calls in cp/m (and/or raw OUT statements) have any real world effect? Eg if you send an OUT to a certain address (0 to 255) on a real board, you can put 8 bits into a latch, or send a byte out of a uart. I'm a bit confused about where bytes go - eg with one version the byte goes to a tv screen but in the other version it goes to the serial port back to the pc, and ?? in another version it goes via a high speed serial link to blade 1. I'm trying to work out how this could fit in with CP/M where you had several devices, like a punch tape reader with standard BIOS calls. It could lead to a standard way of running several serial ports all at once, just make one the console, one the puch tape, one the list device etc.
I'll keep looking through the code - it is all most fascinating.
I had Blade #1 & #2 talking a while back. At the moment, because I am still in development mode, I am back to using the PC to simulate the terminal using PC_text and PC_keyboard and PropTerminal.
VGA would be substitutable for TV - may be a minor change to the call (TV.out and FDX.tx are the same). TV is just used as the object name so we can change PC or terminal without changing the code, just the object.
I have a full 64KB Ram (and am making 256KB available·using bank switching in CPM3) so my code uses the whole lot for CPM whereas heater is restricted to 19K/20K on non-TriBladeProp boards.
We also have different methods for the disks (floppy and hard disks). I am using separate files for each drive (8 floppies at 1MB) and am currently adding 1-4 hard drives at 8MB each. Each file MUST be contiguous within the file and is stored and located under FAT16 and is only using the first 128 bytes of each 512 byte SD sector. Heater is not using FAT16 and all drives are one long contiguous data block on the SD card. I copy my files onto the SD on the PC using windows file copy. I start booting PropDos/PropCmd so I can run any Prop binary stored on the disk which happens to include ZiCog.
Homespun is the compiler (spin & pasm) written by mpark (Michael). It has extensions to use #define which gives heater and I the ability to select various option when compiling (such as hardware). BradC has modified his bstc compiler to also support #define. PropTool no longer compiles our code unless you remove all the #define statements and the associated code.
Heater is tapping the various I/O statements and substituting them in spin. It will be possible (but not yet) to communicate to multiple ports on Blade #1.
Currently I am in the middle of getting the hard disks running. The I need to find out why I have to enter characters twice to get CPM3 working e.g. DDIIRR to do a DIR. No work done in the last 2 days (driving Brisbane - Sydney)
Hope this answers your questions.
I have seen the memory discussions on the other threads but no time to comment yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Yoda: I am using the stock CP/M 2 BIOS from the SIMH Altair Z80 project. Or at least I am now that Peter Schorn has include one of my bug fixes in the SIMH CBIOSX.COM, 3rd May 2009 release.
I'd like to keep it that way as it is a good working reference. I don't need to be debugging a Z80 emulation and hardware emulation AND a custom BIOS all at the same time. Also means it's easy to move disk images between the two emulations.
The only change being the definitions of memory size and number of hard disks in an include file CCPCFG.LIB. I specify 23K RAM for the Prop Demo Board HUB RAM available and only 1 HD as each disk in use eats more RAM space. On the TriBlade the stock CP/M 2 is used but configured for 64K. I don't do any packing of sectors into SD BLOCKS., just one sector one block. I was having a hard enough time getting it working without packing [noparse]:)[/noparse] Then I thought if I do packing I need to be sure I read a block, update the relevant sector then write the block. Awful slow unless I remember I've already have a block in the disk buff from the last read/write. A cache. I got lazy so if you or anyone would like to try packing I'd be very happy.
For CP/M 3 I do modify the BIOS3.COM a little. Nothing to do with disks. But to simplify and speed up bank switched memory on the TriBlade.
I've never come across this "lazy writes" thing you describe. Is that in CP/M 2 BDOS? Where?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I tried BST and homespun
BST doesn't like the #else
and homespun doesn't carry the #defines from zicog_demo.spin into zicog.spin, as it was erroring out saying no HW defined then no CPU when I put the hw define in zicog.spin also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Currently these # directives are only supported by mpark's HomeSpun and BradC's BST compilers. For HomeSpun you have to use the #defines in the Spin code. For the latest BST you can put defines in the project options.
TV.bla bla should probably be renamed (console.bla for example) you will see that you can use TV or VGA or PC.. or whatever object has the same interface to get chars onto a display somewhere. I have had a build running with a TV and my first efforts used a 2 line LCD!
The last release uses 23K of HUB RAM for CP/M on the DemoBoard. No doubt Cluso is fixing it up to use 64K on TriBlade, which he has already got working in previous releases, and to get the hard drives working there.
The DemoBoard build does not use FAT. Not enough space for the code. TriBlade does. It seems to work fine.
All IO instructions are passed from the PASM Z80 emulator to the SPIN peripheral emulation. Here the port numbers and data bytes are interpreted and the appropriate action taken. Console out, disk operations etc. You will see in the code a few lines commented out where I used to take data written to a certain IO address and put it straight to the LEDS of the Demo Board. So it very easy to add emulation of more peripheral devices. What they would do is another matter. The TriBlade has no free pins so everything has to be multiplexed through the serial link eventually. On DemoBoard you have some pins free for more serial ports etc. But then it is running out of space to put more code !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I use BST 018-Pre5 on Linux with the defines placed in the Project dialog. Or I can compile with HomeSpun if I put the defines into the spin code.
On Windows the latest BST release I tried would only compile with the defines in the code. The project settings did not work and everything was going to hell.
I'm just about to try again with the latest BST for Windows.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
as the screen kept clearing
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I presume you are running on a Demo Board.
If there is no SD card it should run up to the A> prompt (after a bunch of disk read error messages)
If there is an SD card it will need a raw CPM disk image (or more) putting onto it. The demo board does not use FAT so that's a bit tricky.
My old method was to take a cpm2.dsk file from the SIMH AlatirZ80 site and use PropTerminal to down load it to the Propeller using cpm2sd.spin running on the prop. This takes about 5 mins over the serial link.
My new method is to use the python script mk_zicog_image.py which takes 8 floppy images and one hard disk image (all available from SIMH) and massages them into a 64Mbyte image file. I then put that image file onto SD card via an SD reader/writer under Linux using the "dd" command. E.g.
dd if=zicog.img of=/dev/sdf
The python script can be modified for different input disk images and can be run under Windows.
I have yet to find a Windows equivalent of "dd" to put raw data on a card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
and will also have the ability to add the HX512 to get the full 64K eventually [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I feel some more #defines coming on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Here is v0.09 with·my updates. Note: Hard Disk is still wip.·I have added the extra #defines to ZiCog009_rr090.spin so that homespun v024 compiles correctly
Baggers:
I am using FAT16 SD files for the disks. It is a much easier method to get files onto SD but uses more hub space so you must have external ram. All files are posted on the TriBlade thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 5/7/2009 4:17:51 PM GMT
I think you are still putting 1 CPM sector into 1 SD sector. What I am proposing is to put 4 CPM sectors into 1 SD sector. I have written programs in python to manipulate the disk images so I am ok there. If you want to send me a copy of 0.09 I can try to give you a hand on the hard disk stuff - have read through Heater's code and have a pretty good understanding of it.
@Heater
The lazy write is generally in the BIOS, but should be pretty easy to implement in the disk code in Cluso's or your code. There is a bit set on one of the BDOS calls to tell you that a write is to a directory entry. You must write them out immediately. On other writes you can cache until you have a physical sectors worth and then do the write. Yes there is some logic to remember what sector you have in the buffer and you may have to do a read before write in some instances to do the lazy write. I think that all can be contained in the SD interface code (if I am lucky).
@Dr A
Send me a note and I can send you a modified PockeTerm code for Blade #1 and code changes to Cluso's last publish for them to work together - very minor changes. I would suggest you make the mod for cross over of the lines between the blades (2 cut traces , 2 wires). I think the change is in the TriBlade thread about a week ago.
Dave
Yes I am only using 1 cpm sector (128 bytes not 137) per SD sector, although I packed the SRAM disk up with 4 x 128 byte sectors per SD sector.
I posted the v0.09 code a few hours ago. I am just about to try reading the hard disk. I will let you know if I get it working.
Lazy write: There is more complexities to this because in my TriBlade the ram bus is shared with the SD bus, so you have to be careful not to permit overlapped I/O due to bus conflicts. The reason we are wasting space on the SD card is to simplify the code... 1x128 byte sector = 1 SD sector. No need to worry about where to place it (offset). There is plenty of room in a 2GB SD card so why worry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I will take a look at the code. I understand what you are saying. When we get to CPM3 you can have 512MB hard drives so the wasted space will become a problem. You would only get one drive on SD and nothing else.
Dave
Did you post the .09 code - I don't see it. Looks like you may have sent it to Heater but did not post ??
Dave
oops Sorry, I seemed to have not posted it where I should have. Posted now (a few posts back) where it should hae been.
When we get CPM3 running I gather we can have 512 byte sectors anyway so that will solve the problem. What files do you think will be that big ??? this is not windoze bloatware
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I was suggesting that if you did not have 512 byte sectors in CPM3 (I was not sure), in the current strategy of a 128 byte sector in a 512 byte SD sector, then a 512MB hard drive would be 2GB (4 x 512MB). Then there would be no more room on a 2GB SD card
Dave
Yes, but do we require a 512MB hard disk??? Currently all my files on the sd card are 32MB (even for the 1MB floppies) and I have 20 odd already because of variations. I haven't bothered to reformat my SD yet to remove the old useless files/drives.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· 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)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
True, but I want to do because we can
Dave
The DPRs for hard disks are defined in the Spin code and fed into the BIOS when it logs a new drive.
In the last ZiCog I included a DPB for a 730K floppy which can be used for a RAM disk. I borrowed that DPR from the SIMH AltairZ80 source code.
Any CP/M experts out there who could dream up a nice DPB for 512 byte sectors and "huge" disk capacity.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I just had a couple of hours today and read most of the thread. I downloaded zilog_v0.6-tst.zip files and
it seems to load and run just fine. (very impressive). I am using a RPM board and PST (Prop Simple Terminal). I used ED to save a five line text file. CTRL-Z to return to Command mode and·E command to return, but it hangs before returning to the prompt. I guess thats just because we ran out of RAM. Ed wants a 5K buffer
Restarting Zilog and cmp2 the text was saved Ok and was able to view the five lines of text (type a:newfile)
Yikes, looks like I will have to wait until we get back to Australia in August, meanwhile there are a couple of other unfinished Propjects !
Anyone know how to config ED to 2K instead of 5k ?
BTW I used PST because I could not get PropTerminal to send CTRL key strokes
Ron
Post Edited (Ron Sutcliffe) : 5/17/2009 8:59:24 AM GMT
I have a Triblade blade #2 soldered up. I can recognise the prop and program the propeller with some demo code.
A few quick questions and help would be most appreciated:
1) Is there a link to the latest software? The version I have is from a few months ago now and might be obsolete. The spin file from further up this page won't compile (either a 'missing top file' error or a 'missing ,' error after the #define CPU_8080). I think I'm missing some files...
2) FAT, not FAT32 format on the SD card, right? Clean format then put a SIMH disk image on the card?
3) I'm going to start simple and just talk to this with text for the moment. So it downloads via pin 39/40 on the Prop. Presumably those pins can then be used for CP/M to talk back to the PC and you could do that with any terminal program. Is there a version of zicog set up to do this (I think there was on some previous posts). And is there a 'terminal' within the Prop IDE, to save shutting down the IDE and starting up hyperterminal? (no problem if there isn't).
4) Can I use a 574 instead of a 573? I'm pretty sure I can as both will latch on the +ve edge of the clock pulse.
5) Is there a link to a 'preferred' disk image. Or will any old SIMH disk image do?
6) and, last but not least, how do I get the sd card into the socket? I hope I haven't soldered something wrong, because there is a RAM chip in the way! The other end of the ram chip lines up with the prop, but even with the two spare holes at the pin 1 end it still needs a couple of mm extra to get the sd card in.
I'm eagerly looking forward to seeing that A> prompt!
Post Edited (Dr_Acula (James Moxham)) : 7/31/2009 3:25:49 AM GMT
1) Link to TriBlade thread with files http://forums.parallax.com/showthread.php?p=786418
2) FAT16 preferrably 32KB clusters. Then copy the files so each is contiguous. (see above link)
3) Yes, Yes and not quite. The terminal program is not actually within the Prop IDE, it is another program. There are 2 terminal programs, PropTerminal and PST (Parallax Serial Terminal). PropTerminal is best for this. I think you get it from the OBEX. Don't waste too much time looking as I can email it if you cannot find it. When the Prop IDE loses focus the program releases the com port (usb in our case). So after downloading, click on the terminal program (PST requires you to also click on the "enable" button). Both PropTerminal and PST release the com port when they lose focus. One other thing, you will require either the Homespun or bst compiler. I was using homespun when I published the code, so use that for now. After saving any changes made to the code in PropTool (Prop IDE), SAVE the code, switch to the compile window (a DOS window and compile). Once again I·should send you the batch files to make this easy. Then use Prop Tool to download the code. This is a bit messy at first. BST has an IDE for all of this, I just haven't had time to use it since Brad added the conditional compile functions.
4) Sorry, no you cannot use a '574. The '573 is a transparent latch meaning that while LE is high data passed through, and latches on the falling edge of LE. You require a 74HC573, 74AHC573. 74LVC573 is also usable.
5) I have posted disk images and instructions (link above). I use VB to convert the SIMH image directly from 137 byte sectors to 128 byte sectors per 512 byte SD sector. That is, I remove the extra (unused) 9 bytes.
6) OOPS - sorry·you have soldered the uSD socket in 180 degrees rotated. The card plugs in from the edge of the pcb.
Note there is a mod to wire -OE from prop to sram. See the TriBlade thead (link above)
Waiting anxiously for another A> prompt
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I'll get homespun then.
Some pre-processing needed on the simh images? Maybe I could put that into my vb.net IDE (which includes a terminal as well). And shell out to homespun so it is all in one place??
Re the sd socket, mine looks like the photo http://bluemagic.biz/clusodocs/tribladeprop_a1d.jpg Maybe it is right? Perhaps it isn't going in because the solder blobs are a bit high on the surface mount. I'll double check when I get home from work. All very exciting!
Post Edited (Dr_Acula (James Moxham)) : 7/31/2009 4:52:06 AM GMT
BTW: I just checked·and zicog009_rr090.spin is the latest code but may not include everything meaning you may also require the code referred to in my post above (see this thread on this page above for rr090)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 7/31/2009 6:22:05 AM GMT