I have to cannibalize the game port (I dont need it) and also 2 NES joystick for the connectors so that I will get 4 more pins enough to drive a sd card..
I can give you the 64K RAM CPM code (CCP, BDOS, etc) already in a file. And the others as well. I went the long route and hindsight is a wonderful thing. Forget loading any of the files from the PC to the Propeller to get them onto the SD card. This is the long way and took me over a week to get working. One evening to get the SD running and transfer files from PC to SD directly.
I am also using 960KB SRAM·for a Ram Disk. Currently thats the way it works, but shouldnt be necessary in the long run, although this is extremely fast and you dont wear out your SD cards (they have a limited number of writes = 100,000 but are cheap enough).
Firstly, I am going to suggest you get PropCMD working on your SD (or microSD - the same) card. I have progressed far enough to know this is a goer and the best route for now. This does not require any RAM, just hub. See PropCMD thread in the last couple of days - it is based on PropDOS. You put the PropCMD code into eeprom which then can run with the SD card. The easiest way to get code onto the SD card is via the PC. I am using microSD for a reason - see TriBladeProp thread - it can plug into and full-size SD converter card, and also a USB converter.
You will need to format your SD card (maximum 2GB) with FAT16. Windowz Vista can do this, but use 32K Clusters (I used the default of 16K, but am going to reformat to 32K). Next you MUST copy the required CPM files to the SD card. These will be the blank drives we are going to use for CPM which will be contained within the FAT system. Most CPM's do not understand FAT and I am not sure for now whether I will embark on this or not. The reason is we need contiguous clusters for the CPM drives because the low level drivers are going to access the file directly as a block of memory.
The reason we will use PropCMD is we can now boot any propeller binary from PropCMD, which of course includes ZiCog. I have this running
Now for your SD card. I don't know the Hydra circuit. I use the CLK pin P28 as used on the propeller eeprom. The -CS pin must be a separate pin with a pullup. I use the SRAM address pins with pullups for DI and DO, but you must be careful of conflicts. If you have any other spare·pin(s) put the DO on it's own pin first. The driver is configurable.
As heater said, we are using homespun to do the conditional compilation.
I will be posting more progress later today and you may have more questions by then. And welcome aboard the "time machine to the past".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The SRAM is now loading fast from the microSD card (<<1 minute) by doing direct sector addressing. The file must be contiguous within the FAT system. Posted below if the ZiCog v0.6 (TriBladeProp v 0.050). This is the top code an does not include the ZiCog Z80 emulator section as I am only running v0.5 currently. We are using mpark's homespun compiler which has conditional compilation for various hardware options - thanks Michael.
Heater: We now need a way to terminate ZiCog and return to (re-boot) PropCMD/PropDOS. Do you have any thoughts? I wondered if we just made one of the illegal Z80 op codes do this - I know how to do the routine, just not how to call it, so I thought this might be the easiest way. Then all we have to do is have a CPM file called xxxxxxxx.COM which when run executes the illegal op code. Your thoughts please.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Hmm, it needs to be an opcode number that does not exist. heater probably has a list of "reverse" opcodes, ie listed by number not by name. I had some ideas but looking through the list of codes, they all unfortunately exist.
Amazing progress BTW. The ram disk does sound a good idea. There is a version of the N8VEM that makes the ram non volatile with a DS1210 but I'm not sure if that would work with a 3.3V supply. I guess if you want something permanent, save it to the flash drive.
I'm always keen on being SIMH compatible if only because I use it all the time and I think others here have played with it.
The way SIMH AltairZ80 does this is to have the emulator intercept control-e (before it gets to the Z80 code) which halts the emulation and drops you back to a SIMH command shell. From there you can type commands into SIMH to inspect Z80 memory space, single step the Z80, reset the Z80, go, change Z80 registers etc etc or "quit" SIMH altogether.
So a first step here would be to intercept control-e and from there stop the emulator COG and drop back to PropCMD/PropDos.
Another thing SIMH does is to have a virtual I/O port that can be used to control the simulator from within a CP/M program. For example there is a CP/M program CPU.COM that can find out from SIMH what CPU is being emulated Z80 or 8080 and it can command SIMH to change CPU type on the fly.
There is another command RSETSIMH.COM that does pretty much what it says.
So your program xxxxxxx.COM could write a new command that we define to the SIMH control I/O port address (Or we could reserve an unused port of our own for PropDos stuff) the emulator seeing this would do as control-e above.
I'd rather not use illegal opcodes to do this. Eventually I'd like to trap use of illegal codes in such a way that the user knows what is going on in their program.
At risk of slowing emulation of I/O down, we could of course have the OUT instruction emulation check for writes to the PropDos port before it even got to the Spin emulator part and then do a cogstop itself. I prefer the former approach.
Would be cool to be able to type "go" after hitting control-e (or whatever caused a break) and have the emulation continue from where it left off. Trouble is we would have to use the break mechanism we have in ZiCog all the time which would slow us down a lot.
P.S. There is one legal op code we can use for this "HLT". SIMH also uses halt to drop in it's command shell. The "xxxxxxxx.COM" could be "halt.com" it only needs to contain one byte, the HLT op code which is $76. When SIMH sees this we get "HALT instruction, PC xxxx (HALT)" coming out. So this is the easiest thing to do. You can see a label "halt" in zicog waiting to handle this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ctrl-e sounds good and easy for starters, or HLT. A program PROPDOS.COM or·maybe we could boot prop code directly by xxxxxxxx.SPN (for spin). It's your choice. I will just put the rest of the code there to go back to PropDOS/PropCMD for now, with the possibility of a parameter for running a xxxxxxxx.SPN program, similar to how we load ZiCog from PropDOS/PropCMD.
How do we get the other drives working on the SD card? I am not sure of how to implement/code the in_dskread and out_dskwrit routines. Should it be SIMH/Altair based or do you want to investigate FAT16 - easier for now with SIMH/Altair??? and just contiguous files within FAT as I have created now???
I am almost ready to get OBC's·VT100 running on Blade #1. And the UFDX running (ultra high speed full duplex serial).
James: I found the SRAM survived with the power off for over an hour, so to back it up would be easy - but we could just as easily save back to SD. The loading of SRAM takes a number of seconds, far less than CPM to boot or MBASIC to load.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Clusso, it's time to write your first CP/M program on the TriBlade[noparse]:)[/noparse] This is how to create the HALT.COM program:
64K CP/M Version 2.2 (SIMH ALTAIR 8800, BIOS V1.25, 2 HD, 15-Jan-07)
A>DDT
DDT VERS 2.2
-A100
0100 HLT
0101
-^C
A>
A>
A>SAVE 1 HALT.COM
A>
A>
A>
A>HALT
HALT instruction, PC: 00100 (HALT)
sim>
What does this do? First we run CP/M's debugger DDT and with it's "a" command we assemble the HLT instruction at address 0100, which is where all *.COM programs are loaded and run from. Hitting just "return" gets us out of assembling and back to the DDT prompt. Then we exit DDT with control-C. From the cp/m prompt we issue a SAVE command which writes 1 block of 256 bytes from address 0100 to the given file name HALT.COM. Use whatever name you like.
Now we have a .COM file with the halt instruction as the first byte. So typing "halt" gets us out of CP/M to the SIMH command line prompt.
Who said you can't develop in assembler on the Propeller?
Not sure what you mean by the "xxxxxxxx.SPN" thing. Please elaborate. If you are thinking of passing a file name back to PropDos for it to load and execute after stopping ZiCog we should do it through a reserved I/O port.
Other disk drives: I'd really like it to be SIMH/Altair compatible, as it is in the zicog_demo. We should be able to put whatever we like on a disk in SIMH and just use the resulting images. This makes life much easier.
FAT16 is right out. We could of course map CP/M files onto FAT16 files, people have done such things. This is a lot of work and basically means throwing out the CP/M BDOS layer and writing a new FAT16 based one. Or it means catching the emulator on entry into the BDOS and then emulating the BDOS, in our case in Spin. As I say people have done this to get CP/M programs to run under MSDOS for example. I don't like this for the following reasons:
1. It's getting far to far away from the spirit of creating a CP/M machine for the Prop.
2. It would mean not being able to experiment with the other variants of CP/M available, for example SIMH has CP/M 3 and M/PM and others.
3. It's a lot of work !!!
4. We already have native CP/M drives working.
So what to do ?
The current ZiCog demo code assumes there is a 1 to 1 mapping of disk sectors to SD card blocks. Only the first 137 bytes of each SD card block are used. These SD blocks are populated by the cpm2sd.spin program. When reading a sector ZiCog calculates the required SD block from the disk drive number, the track number and the sector number. The resulting number gets us to the correct SD block starting from the beginning of the SD card.
But now we have FAT on the card, so what we need is a single large file on the card that is big enough to contain 8 x 1MB floppy disk images and, for the future, 4 x 8MB hard disk images. That is, it has as many SD blocks as there are sectors in all those disk, much larger than 16MB. I think we have enough space to waste here.
We need to write this file on a newly formatted card so that it is contiguous.
We need to know the first SD block of this file. Ariba has shown how to do this.
From then on all changes to the file must be done from CP/M or by direct access to it's sectors from Spin. Using the FAT routines to update it (on the Prop or PC) will probably fragment it.
Given all that, all that is left to do is add the number of the start block to the block number calculated when looking for a sector. And that's it[noparse]:)[/noparse]
From there on the CP/M format command should work on the floppy drives and we have 7 empty drives.
This file can be created on the SD card in Spin or on the PC just by writing blocks of zeros to whatever file name on a new card. On the PC we could make a little program that takes SIMH disk images and writes their sectors to a file in SD card sized blocks, we then write the resulting file to a clean SD card.
Alternatively we could do all the above using 8 different floppy files and 4 different hard disk files. But then we need to find 12 starting block positions and arrange to read from the correct file offset for the accessed drive. Slows things down I guess.
Or we need a seek routine in the FAT code so that fragmentation does not matter. Could be slow though.
As usual, hope all that makes sense [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm glad that a hydra owner can join in, I still had no real success but at least I modified the sources to be more hydra compatible, i.e. databus back to P16..P23 and C0/C1 command lines in the P0..P8 range so it can be expressed with constants.
I'm still using different pins for clock and reset, but that it's not a big deal since hydra uses P30 for clock and the Propeller RST for reset, so you need a long mask for clock anyway.
I can send you what I've got if you wish, the reasons why I've esitated to post until now...
sources are a mess (I mean *I* have messed it ) because I have the terrible habit to rename vars and methods just to suit my·ahestetic taste (like tv.str -> cio.putc etc )
and also·I've been busy trying to fix·my SD card, but just when I was done I *HAD* to remove it from protoboard and·move it to demoboard·to try Ariba's excellent MIDI player... now it's giving trouble again => maybe I·need a less clumsy one from ucontroller.com
Re "I'd really like it to be SIMH/Altair compatible, as it is in the zicog_demo."
Yes, absolutely. All your musings make a lot of sense. I'm not sure I have the exact answer. But it is possible to take an altair simh drive image and strip it right back to only having the very bare essential files on it - eg you have to have W and R to read and write within the simh, and STAT and PIP are pretty essential too. One could probably make a case for a few more files. But then you could simply have two almost blank images - one is 1meg and one is 8 meg and then you can build on those.
I have some software that can automate loading up simh drives with files. The images on the simh site are a very good starting point though.
Hmm - if I reformat my USB flash drive and then load it up with music, it plays those songs in the order I loaded them. So does that mean if you sent 4x1meg .dsk files and then 4x8meg files over to an SD card, in the same order, and always following a reformat, would their start addresses be known and predictable? If so, it could greatly simplify things as you don't need to know much about FAT etc.
Once those .dsk files are on the sd card, if you want to edit them on a PC you would need to bring them back into the simh, but that would not be much of a hassle and again could be automated with a small PC program that reads the sd card and then starts the simh and telnets into it. I've got all that sort of thing working apart from reading the SD card. If you want to go down this road I could share some vb.net code I've written that talks to the simh and works with a vt100 terminal emulation.
OR - if you are in a CP/M emulation and you want to transfer a file, use xmodem via a serial connection. I've got that automated too. I've also got a program running on CP/M that creates a "fake" drive G which is actually the local folder on the PC, and then you can talk to this drive using CP/M PIP etc. Or download it using familiar windows file listings. For transferring one file at 38400 baud it is probably marginal which is quicker - sending it via xmodem or taking the sd card out and firing up the simh.
Thanks for the HALT code. I understand, no problems.
FAT16 - Exactly. The CPM drive files are already done. I have a VB program to do this. I posted a ziped version of an empty file a few posts (days) ago. They are 32MB files and only using the first 128 bytes of each 512 byte sector and they are contiguous. I have A..H but of course we are using A as a ram disk. If they need to be smaller, then we will just use the first sectors of the file. I can now find the first sector on the SD card, so the driver is now easy to just add a constant for the drive number and access directly into the sector required on the SD block, and it will be fast. I agree with you that this way we can use whatever flavour of CPM anyone likes.
I was just thinking aloud re the xxxxxxxx.SPN thing. I think we need a method to pass the filename when using a HALT instruction so that we can just load a prop binary "xxxxxxxx.SPN" and execute it to reboot the prop. I will think on this further. Just getting HALT will be a great bonus.
Alessandro:
If you are just using a straight 64KB CPM and is the same as heaters, I have this in a 1MB file which can be copied to your SD card using the PC directly. Saves loading each time. Just modify my routine to load only the first 64KB. This is in 4x128 byte sectors per SD 512byte sector. see the code I posted last night. I posted the 1MB file a few days ago. It would be good if you thought about PropDOS/PropCMD to host this.
James:
I am doing all this directly on the PC. It is so much faster. Just plug the card into the PC and format and copy. I·have found out how to find the first sd sector of each file (easy once you know how - see my·previous post for the code) and provided you created them in order on a newly formatted sd card they are contiguous. I have verified this. I am using microSD disks because I have a USB microSD carrier and a SD microSD carrier, so my pcs can see them and format them. see the TriBladeProp thread for photos. From my comments above, you will realise I am using the underlying FAT as the host so I can use prop code also. The CPM disks are just contiguous sd sectors contained in a FAT file, so accessing the CPM drives is just normal sector access with an offset for the file base (easy).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Goodness me, one has to log into this thread three times a day just to keep up!
Thinking about it there would be uses for both 8mb and 1mb sized images. 8mb is great for storage of lots of files. But 1mb is also convenient to package up files in groups, eg basic, or wordstar, or bds C. This gets around the lack of directories in CP/M.
Another thought - with two memory chips as you have this is 1mb as well, you could do a PIP *.* type of transfer of all the files in a .dsk file into ram as a single operation. Maybe in spin or in CP/M.
HALT makes a lot of sense to use as a stop command.
James: Once the extra disks (hard disks) are functioning on the SD card, we can do a CPM file "copy" between disks easily. There is plenty of room on the SD card, so the files may as well be the full 8MB (32MB used). Even if we only use them as 1MB drives.
I am initially loading the 1MB SRAM (64K Z80 plus 960K of disk) by calling in spin, but the work is done in pasm by two drivers doing 8KB blocks at a time, so it's quick.
Heater: The halt program did not work. I had to get ctl-c and ctl-z to work (have used F1, F2, F3 to convert to Ctl Z, S, C). Perhaps it is because I cannot run v0.6 of the Z80 section. I will have to see why it is not running.
Just picked up my VGA monitor for the VT100/ASCII Terminal emulator on Blade #1. Tonights exercise
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
With the ZiCog as I last left it the HALT instruction is handled the same way as a NOP (or any undocumented instruction). So you would not see anything happen. There is a "halt" label in the code at the same place as "fetch" so for it to do anything you have to move that label and add some code to it.
I think if we want to pass a file name or other parameter out of ZiCog we should not use HALT but a reserved virtual I/O port. Hmm ... or both, first write the parameter with OUTs to the reserved port for the emulator to pick up and then HALT.
I'll try and find out what has happened to v0.6.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
HLT not working? heater will be able to help with the actual code, but did you create a new HALT.COM using the save etc, or use one already made? ie is it that the halt instruction was not properly handled, or that the halt never ran in the first place?
8mb on a CP/M disk? We will be spoilt! The simh only has 8 disks because the simulator is coded that way, but I suppose there is no reason you could not have 26, from A to Z. You could have C on drive C, Mbasic on drive M, Wordstar on drive W and Zork on drive Z.
A VGA monitor has arrived? This sounds promising. My work bench currently has a PC sitting next to a N8VEM working on its own monitor. It makes it much easier troubleshooting when a computer has its own monitor and keyboard. I'm looking forward to that photo of a keyboard, vga monitor and triblade. Sounds like you are very close now. Very exciting.
Off topic, I'm currently working with some Lantronix serial to ethernet devices, with a view to getting a CP/M board online as a BBS or game server or whatever. Who knows, soon we may be able to link some boards together?
Dr_A: SIMH Altair has 12 disks ! You can have 8 * 1M floppy disks A: to H: and 4 * 8M hard disks I: to L:
You can even change the ROM boot loader for one that boots from hard disk.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Trapping an OUT sounds interesting. You can trap an out to one port to do a halt, and then maybe have other bits of spin code to trap other OUT instructions, eg out to a psuedo uart that sets a baud rate, and out to another port that sends out a byte to that port. So it is something that could be easily expanded in spin once one function is written.
"MP/M II can support up to 16 logical drives, each containing up to 512 Megabytes, for a maximum of 8 Gigabytes of on-line storage. Any one file can be up to 32 Megabytes in size,
Not to mention multi-user and multi-tasking. So guess what I want to do next? We might need some hardware assistance for the 400K of bank switched memory though. Cluso......
Trapping INs and OUTs is exactly what ZiCoG does. In much the same way as SIMH. So yes easily expandable. In fact I have to build on the SIMH control port to implement the hard disk emulation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
We are up and running with OBC's VT100 Terminal. There are some issues of speed (buffer too small so I have reduced to 4800 baud) and also the shutdown of the cogs and restart when PropCMD passes control to ZiCog.
Anyway here are some photo's - one is PropCmd and the next is ZiCog which has been booted from PropCmd.
The code posted: PropCmd is in Blade #2 and PropComm2 is in Blade #1 and they communicate over the P31/P30 pins (no PC involved in the whole process) WARNING: I have shunts on the TriBladeProp PCB that join P30-P30 and P31-P31, so Blade #1 reverses the SI and SO pins.
James: I saved the new HALT.COM program but it hung - I don't have heaters latest code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
So now with VT100 you can run the WordMaster (WM.COM) full screen text editor. You do realise you have a complete software development system running there now. Just need to knock up that spin compiler for CP/M [noparse]:)[/noparse]
The WORM game is a nice little test of VT100.
Screen shots please[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Amazing. Can you run wordstar - that will test the vt100. If you can do that, (open it in N mode for Non document), you will be able to write your own little assembly program and assemble it on the actual computer. Easier than using DDT.
Keyboard working?
What next - the third propeller that does the I/O. Any chance of one or two serial ports that you can address within CP/M with OUT and IN instructions?
I'm off to code a Lantronix serial/ethernet device, but if I get that working we might be able to get a couple of CP/M machines chatting to each other...
James - yes, keyboard working. Can you email me wordstar file?
Yes the third prop will do I/O - multiple serial or whatever.
Here is a shot of worm (it's in German), and of the TriBladeProp while running so you can see the connections - no USB to PC, just keyboard, vga and power (and before someone says I have the keyboard in the mouse connector - yes it is because I have sram fitted and otherwise it will conflict).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Congratulations to all for this important milestone!
@Cluso, about the SD image I thought it was specific being 1MB, and didn't think about chopping the first 64KB... I'll give it a try as soon as I get the SD card working again
I have just emailed the wordstar image. I'm pretty sure it is the vt100 one - let me know if any problems. It is a simh .dsk image - this is probably the de-facto format for this system. Use W or R to move files in and out and then send the file on. I sent both the .dsk and also the little boot file (no extension) that the simh needs - I'm not sure if you need this little file as well.
So wordstar is next, multiple disks, and the I/O Blade #3, Trubo Pascal, Vedit anyone?,... Stay tuned...
I mentioned a speed issue between the props above. I think is has to do with: the buffer size in FDX, no delay in starting FDX and sending chars, and maybe bus has no pullups when tristated. All are easily solved and I have 2 uncommited resistors on the board just in case I needed them.
A few have asked - I have a few TriBladeProp PCBs available (sorry, no parts yet but I may have to order some soon). See www.bluemagic.biz/cluso.htm or the TriBladeProp thread (and mention you are a forum member for current discount to US$25 + $4.50 postage for bare PCB). There is an errata listed on my website and the TriBladeProp thread (only 1 actual wire mod and the transistor pins needs to be fitted differently)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
No free pin on the hydra box..
I have to cannibalize the game port (I dont need it) and also 2 NES joystick for the connectors
Regards
Gianni
I can give you the 64K RAM CPM code (CCP, BDOS, etc) already in a file. And the others as well. I went the long route and hindsight is a wonderful thing. Forget loading any of the files from the PC to the Propeller to get them onto the SD card. This is the long way and took me over a week to get working. One evening to get the SD running and transfer files from PC to SD directly.
I am also using 960KB SRAM·for a Ram Disk. Currently thats the way it works, but shouldnt be necessary in the long run, although this is extremely fast and you dont wear out your SD cards (they have a limited number of writes = 100,000 but are cheap enough).
Firstly, I am going to suggest you get PropCMD working on your SD (or microSD - the same) card. I have progressed far enough to know this is a goer and the best route for now. This does not require any RAM, just hub. See PropCMD thread in the last couple of days - it is based on PropDOS. You put the PropCMD code into eeprom which then can run with the SD card. The easiest way to get code onto the SD card is via the PC. I am using microSD for a reason - see TriBladeProp thread - it can plug into and full-size SD converter card, and also a USB converter.
You will need to format your SD card (maximum 2GB) with FAT16. Windowz Vista can do this, but use 32K Clusters (I used the default of 16K, but am going to reformat to 32K). Next you MUST copy the required CPM files to the SD card. These will be the blank drives we are going to use for CPM which will be contained within the FAT system. Most CPM's do not understand FAT and I am not sure for now whether I will embark on this or not. The reason is we need contiguous clusters for the CPM drives because the low level drivers are going to access the file directly as a block of memory.
The reason we will use PropCMD is we can now boot any propeller binary from PropCMD, which of course includes ZiCog. I have this running
Now for your SD card. I don't know the Hydra circuit. I use the CLK pin P28 as used on the propeller eeprom. The -CS pin must be a separate pin with a pullup. I use the SRAM address pins with pullups for DI and DO, but you must be careful of conflicts. If you have any other spare·pin(s) put the DO on it's own pin first. The driver is configurable.
As heater said, we are using homespun to do the conditional compilation.
I will be posting more progress later today and you may have more questions by then. And welcome aboard the "time machine to the past".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Heater: We now need a way to terminate ZiCog and return to (re-boot) PropCMD/PropDOS. Do you have any thoughts? I wondered if we just made one of the illegal Z80 op codes do this - I know how to do the routine, just not how to call it, so I thought this might be the easiest way. Then all we have to do is have a CPM file called xxxxxxxx.COM which when run executes the illegal op code. Your thoughts please.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Amazing progress BTW. The ram disk does sound a good idea. There is a version of the N8VEM that makes the ram non volatile with a DS1210 but I'm not sure if that would work with a 3.3V supply. I guess if you want something permanent, save it to the flash drive.
The way SIMH AltairZ80 does this is to have the emulator intercept control-e (before it gets to the Z80 code) which halts the emulation and drops you back to a SIMH command shell. From there you can type commands into SIMH to inspect Z80 memory space, single step the Z80, reset the Z80, go, change Z80 registers etc etc or "quit" SIMH altogether.
So a first step here would be to intercept control-e and from there stop the emulator COG and drop back to PropCMD/PropDos.
Another thing SIMH does is to have a virtual I/O port that can be used to control the simulator from within a CP/M program. For example there is a CP/M program CPU.COM that can find out from SIMH what CPU is being emulated Z80 or 8080 and it can command SIMH to change CPU type on the fly.
There is another command RSETSIMH.COM that does pretty much what it says.
So your program xxxxxxx.COM could write a new command that we define to the SIMH control I/O port address (Or we could reserve an unused port of our own for PropDos stuff) the emulator seeing this would do as control-e above.
I'd rather not use illegal opcodes to do this. Eventually I'd like to trap use of illegal codes in such a way that the user knows what is going on in their program.
At risk of slowing emulation of I/O down, we could of course have the OUT instruction emulation check for writes to the PropDos port before it even got to the Spin emulator part and then do a cogstop itself. I prefer the former approach.
Would be cool to be able to type "go" after hitting control-e (or whatever caused a break) and have the emulation continue from where it left off. Trouble is we would have to use the break mechanism we have in ZiCog all the time which would slow us down a lot.
P.S. There is one legal op code we can use for this "HLT". SIMH also uses halt to drop in it's command shell. The "xxxxxxxx.COM" could be "halt.com" it only needs to contain one byte, the HLT op code which is $76. When SIMH sees this we get "HALT instruction, PC xxxx (HALT)" coming out. So this is the easiest thing to do. You can see a label "halt" in zicog waiting to handle this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
How do we get the other drives working on the SD card? I am not sure of how to implement/code the in_dskread and out_dskwrit routines. Should it be SIMH/Altair based or do you want to investigate FAT16 - easier for now with SIMH/Altair??? and just contiguous files within FAT as I have created now???
I am almost ready to get OBC's·VT100 running on Blade #1. And the UFDX running (ultra high speed full duplex serial).
James: I found the SRAM survived with the power off for over an hour, so to back it up would be easy - but we could just as easily save back to SD. The loading of SRAM takes a number of seconds, far less than CPM to boot or MBASIC to load.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
What does this do? First we run CP/M's debugger DDT and with it's "a" command we assemble the HLT instruction at address 0100, which is where all *.COM programs are loaded and run from. Hitting just "return" gets us out of assembling and back to the DDT prompt. Then we exit DDT with control-C. From the cp/m prompt we issue a SAVE command which writes 1 block of 256 bytes from address 0100 to the given file name HALT.COM. Use whatever name you like.
Now we have a .COM file with the halt instruction as the first byte. So typing "halt" gets us out of CP/M to the SIMH command line prompt.
Who said you can't develop in assembler on the Propeller?
Not sure what you mean by the "xxxxxxxx.SPN" thing. Please elaborate. If you are thinking of passing a file name back to PropDos for it to load and execute after stopping ZiCog we should do it through a reserved I/O port.
Other disk drives: I'd really like it to be SIMH/Altair compatible, as it is in the zicog_demo. We should be able to put whatever we like on a disk in SIMH and just use the resulting images. This makes life much easier.
FAT16 is right out. We could of course map CP/M files onto FAT16 files, people have done such things. This is a lot of work and basically means throwing out the CP/M BDOS layer and writing a new FAT16 based one. Or it means catching the emulator on entry into the BDOS and then emulating the BDOS, in our case in Spin. As I say people have done this to get CP/M programs to run under MSDOS for example. I don't like this for the following reasons:
1. It's getting far to far away from the spirit of creating a CP/M machine for the Prop.
2. It would mean not being able to experiment with the other variants of CP/M available, for example SIMH has CP/M 3 and M/PM and others.
3. It's a lot of work !!!
4. We already have native CP/M drives working.
So what to do ?
The current ZiCog demo code assumes there is a 1 to 1 mapping of disk sectors to SD card blocks. Only the first 137 bytes of each SD card block are used. These SD blocks are populated by the cpm2sd.spin program. When reading a sector ZiCog calculates the required SD block from the disk drive number, the track number and the sector number. The resulting number gets us to the correct SD block starting from the beginning of the SD card.
But now we have FAT on the card, so what we need is a single large file on the card that is big enough to contain 8 x 1MB floppy disk images and, for the future, 4 x 8MB hard disk images. That is, it has as many SD blocks as there are sectors in all those disk, much larger than 16MB. I think we have enough space to waste here.
We need to write this file on a newly formatted card so that it is contiguous.
We need to know the first SD block of this file. Ariba has shown how to do this.
From then on all changes to the file must be done from CP/M or by direct access to it's sectors from Spin. Using the FAT routines to update it (on the Prop or PC) will probably fragment it.
Given all that, all that is left to do is add the number of the start block to the block number calculated when looking for a sector. And that's it[noparse]:)[/noparse]
From there on the CP/M format command should work on the floppy drives and we have 7 empty drives.
This file can be created on the SD card in Spin or on the PC just by writing blocks of zeros to whatever file name on a new card. On the PC we could make a little program that takes SIMH disk images and writes their sectors to a file in SD card sized blocks, we then write the resulting file to a clean SD card.
Alternatively we could do all the above using 8 different floppy files and 4 different hard disk files. But then we need to find 12 starting block positions and arrange to read from the correct file offset for the accessed drive. Slows things down I guess.
Or we need a seek routine in the FAT code so that fragmentation does not matter. Could be slow though.
As usual, hope all that makes sense [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@Gianni
I'm glad that a hydra owner can join in, I still had no real success but at least I modified the sources to be more hydra compatible, i.e. databus back to P16..P23 and C0/C1 command lines in the P0..P8 range so it can be expressed with constants.
I'm still using different pins for clock and reset, but that it's not a big deal since hydra uses P30 for clock and the Propeller RST for reset, so you need a long mask for clock anyway.
I can send you what I've got if you wish, the reasons why I've esitated to post until now...
sources are a mess (I mean *I* have messed it
and also·I've been busy trying to fix·my SD card, but just when I was done I *HAD* to remove it from protoboard and·move it to demoboard·to try Ariba's excellent MIDI player... now it's giving trouble again => maybe I·need a less clumsy one from ucontroller.com
Ciao
Alessandro
Yes, absolutely. All your musings make a lot of sense. I'm not sure I have the exact answer. But it is possible to take an altair simh drive image and strip it right back to only having the very bare essential files on it - eg you have to have W and R to read and write within the simh, and STAT and PIP are pretty essential too. One could probably make a case for a few more files. But then you could simply have two almost blank images - one is 1meg and one is 8 meg and then you can build on those.
I have some software that can automate loading up simh drives with files. The images on the simh site are a very good starting point though.
Hmm - if I reformat my USB flash drive and then load it up with music, it plays those songs in the order I loaded them. So does that mean if you sent 4x1meg .dsk files and then 4x8meg files over to an SD card, in the same order, and always following a reformat, would their start addresses be known and predictable? If so, it could greatly simplify things as you don't need to know much about FAT etc.
Once those .dsk files are on the sd card, if you want to edit them on a PC you would need to bring them back into the simh, but that would not be much of a hassle and again could be automated with a small PC program that reads the sd card and then starts the simh and telnets into it. I've got all that sort of thing working apart from reading the SD card. If you want to go down this road I could share some vb.net code I've written that talks to the simh and works with a vt100 terminal emulation.
OR - if you are in a CP/M emulation and you want to transfer a file, use xmodem via a serial connection. I've got that automated too. I've also got a program running on CP/M that creates a "fake" drive G which is actually the local folder on the PC, and then you can talk to this drive using CP/M PIP etc. Or download it using familiar windows file listings. For transferring one file at 38400 baud it is probably marginal which is quicker - sending it via xmodem or taking the sd card out and firing up the simh.
Thanks for the HALT code. I understand, no problems.
FAT16 - Exactly. The CPM drive files are already done. I have a VB program to do this. I posted a ziped version of an empty file a few posts (days) ago. They are 32MB files and only using the first 128 bytes of each 512 byte sector and they are contiguous. I have A..H but of course we are using A as a ram disk. If they need to be smaller, then we will just use the first sectors of the file. I can now find the first sector on the SD card, so the driver is now easy to just add a constant for the drive number and access directly into the sector required on the SD block, and it will be fast. I agree with you that this way we can use whatever flavour of CPM anyone likes.
I was just thinking aloud re the xxxxxxxx.SPN thing. I think we need a method to pass the filename when using a HALT instruction so that we can just load a prop binary "xxxxxxxx.SPN" and execute it to reboot the prop. I will think on this further. Just getting HALT will be a great bonus.
Alessandro:
If you are just using a straight 64KB CPM and is the same as heaters, I have this in a 1MB file which can be copied to your SD card using the PC directly. Saves loading each time. Just modify my routine to load only the first 64KB. This is in 4x128 byte sectors per SD 512byte sector. see the code I posted last night. I posted the 1MB file a few days ago. It would be good if you thought about PropDOS/PropCMD to host this.
James:
I am doing all this directly on the PC. It is so much faster. Just plug the card into the PC and format and copy. I·have found out how to find the first sd sector of each file (easy once you know how - see my·previous post for the code) and provided you created them in order on a newly formatted sd card they are contiguous. I have verified this. I am using microSD disks because I have a USB microSD carrier and a SD microSD carrier, so my pcs can see them and format them. see the TriBladeProp thread for photos. From my comments above, you will realise I am using the underlying FAT as the host so I can use prop code also. The CPM disks are just contiguous sd sectors contained in a FAT file, so accessing the CPM drives is just normal sector access with an offset for the file base (easy).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Thinking about it there would be uses for both 8mb and 1mb sized images. 8mb is great for storage of lots of files. But 1mb is also convenient to package up files in groups, eg basic, or wordstar, or bds C. This gets around the lack of directories in CP/M.
Another thought - with two memory chips as you have this is 1mb as well, you could do a PIP *.* type of transfer of all the files in a .dsk file into ram as a single operation. Maybe in spin or in CP/M.
HALT makes a lot of sense to use as a stop command.
I'm looking forward to the next update!
I am initially loading the 1MB SRAM (64K Z80 plus 960K of disk) by calling in spin, but the work is done in pasm by two drivers doing 8KB blocks at a time, so it's quick.
Heater: The halt program did not work. I had to get ctl-c and ctl-z to work (have used F1, F2, F3 to convert to Ctl Z, S, C). Perhaps it is because I cannot run v0.6 of the Z80 section. I will have to see why it is not running.
Just picked up my VGA monitor for the VT100/ASCII Terminal emulator on Blade #1. Tonights exercise
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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 think if we want to pass a file name or other parameter out of ZiCog we should not use HALT but a reserved virtual I/O port. Hmm ... or both, first write the parameter with OUTs to the reserved port for the emulator to pick up and then HALT.
I'll try and find out what has happened to v0.6.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
8mb on a CP/M disk? We will be spoilt! The simh only has 8 disks because the simulator is coded that way, but I suppose there is no reason you could not have 26, from A to Z. You could have C on drive C, Mbasic on drive M, Wordstar on drive W and Zork on drive Z.
A VGA monitor has arrived? This sounds promising. My work bench currently has a PC sitting next to a N8VEM working on its own monitor. It makes it much easier troubleshooting when a computer has its own monitor and keyboard. I'm looking forward to that photo of a keyboard, vga monitor and triblade. Sounds like you are very close now. Very exciting.
Off topic, I'm currently working with some Lantronix serial to ethernet devices, with a view to getting a CP/M board online as a BBS or game server or whatever. Who knows, soon we may be able to link some boards together?
You can even change the ROM boot loader for one that boots from hard disk.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Trapping an OUT sounds interesting. You can trap an out to one port to do a halt, and then maybe have other bits of spin code to trap other OUT instructions, eg out to a psuedo uart that sets a baud rate, and out to another port that sends out a byte to that port. So it is something that could be easily expanded in spin once one function is written.
"MP/M II can support up to 16 logical drives, each containing up to 512 Megabytes, for a maximum of 8 Gigabytes of on-line storage. Any one file can be up to 32 Megabytes in size,
Not to mention multi-user and multi-tasking. So guess what I want to do next? We might need some hardware assistance for the 400K of bank switched memory though. Cluso......
Trapping INs and OUTs is exactly what ZiCoG does. In much the same way as SIMH. So yes easily expandable. In fact I have to build on the SIMH control port to implement the hard disk emulation.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
We are up and running with OBC's VT100 Terminal. There are some issues of speed (buffer too small so I have reduced to 4800 baud) and also the shutdown of the cogs and restart when PropCMD passes control to ZiCog.
Anyway here are some photo's - one is PropCmd and the next is ZiCog which has been booted from PropCmd.
The code posted: PropCmd is in Blade #2 and PropComm2 is in Blade #1 and they communicate over the P31/P30 pins (no PC involved in the whole process) WARNING: I have shunts on the TriBladeProp PCB that join P30-P30 and P31-P31, so Blade #1 reverses the SI and SO pins.
James: I saved the new HALT.COM program but it hung - I don't have heaters latest code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
So now with VT100 you can run the WordMaster (WM.COM) full screen text editor. You do realise you have a complete software development system running there now. Just need to knock up that spin compiler for CP/M [noparse]:)[/noparse]
The WORM game is a nice little test of VT100.
Screen shots please[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
see post above.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Amazing. Can you run wordstar - that will test the vt100. If you can do that, (open it in N mode for Non document), you will be able to write your own little assembly program and assemble it on the actual computer. Easier than using DDT.
Keyboard working?
What next - the third propeller that does the I/O. Any chance of one or two serial ports that you can address within CP/M with OUT and IN instructions?
I'm off to code a Lantronix serial/ethernet device, but if I get that working we might be able to get a couple of CP/M machines chatting to each other...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Looking forward to seeing a Wordstar screenshot soon!!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Yes the third prop will do I/O - multiple serial or whatever.
Here is a shot of worm (it's in German), and of the TriBladeProp while running so you can see the connections - no USB to PC, just keyboard, vga and power (and before someone says I have the keyboard in the mouse connector - yes it is because I have sram fitted and otherwise it will conflict).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Yes the Prop is growing up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@Cluso, about the SD image I thought it was specific being 1MB, and didn't think about chopping the first 64KB... I'll give it a try as soon as I get the SD card working again
Heater emailed the link to the Altair emulator site http://www.schorn.ch/cpm/intro.php
So wordstar is next, multiple disks, and the I/O Blade #3, Trubo Pascal, Vedit anyone?,... Stay tuned...
I mentioned a speed issue between the props above. I think is has to do with: the buffer size in FDX, no delay in starting FDX and sending chars, and maybe bus has no pullups when tristated. All are easily solved and I have 2 uncommited resistors on the board just in case I needed them.
A few have asked - I have a few TriBladeProp PCBs available (sorry, no parts yet but I may have to order some soon). See www.bluemagic.biz/cluso.htm or the TriBladeProp thread (and mention you are a forum member for current discount to US$25 + $4.50 postage for bare PCB). There is an errata listed on my website and the TriBladeProp thread (only 1 actual wire mod and the transistor pins needs to be fitted differently)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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