I added PS/2 keyboard support to the Space Invaders "ports" object. There are two top-level objects in the archive: one for the hacked joystick hardware and one for the pure demo board with no extra parts. You have to (legally) embed the ROM yourself.
My main interest from here is a generic "CPU" interface that can be stopped and restarted. It can be single-stepped. The HALT opcode allows for breakpoints. A USB monitor program (takes a COG) would connect to an Eclipse plugin allowing an assembly programmer to edit and debug assembly in the Eclipse graphical interface.
Eventually I would like to have several CPUs ... 6809, 6502, Z80, etc. Anybody else interested in this direction? Maybe take it to a different thread?
there are some other cpu emulations besides the z80. Best to search the relevant thread for the cpu. If you cannot find one, best to start a new thread and ask. Often there are threads but the searches fail to find them - someone will chime in if it exists.
I have the z80 halt instruction returning to a prop os now and that can run the z80 again.
I started on a 6809 emulator a long while back.http://forums.parallax.com/showthread.php?113233-MoCog-A-Motorola-6809-emulator-for-the-Propeller
The ZiCog emulator is only missing a few Z80 opcodes that are never used in the CP/M software I wanted up and running so there was no great pressure to add them. One day I hope to return to that.
The old PropAltair emulator did 8080 perfectly if I remember correctly. At least as far as the EX8080 test program I have is concerned.
Some folks started out on 6502 emulations. Not sure what happened to those efforts.
Then the is th qZ80 emulator from PullMoll http://forums.parallax.com/showthread.php?121579-qZ80-the-third-shot which I believe has all z80 ops working correctly. Sadly he has not shown up here for a long while.
Do you have such an eclipse plugin? That takes debugging Z80 code a billion miles away from debugging ynder CP/M!!
I just checked out the videos of the Expo presentations for Friday. Wow! There you are opening proceedings with Space Invaders and ZiCog gets a mention. Fantastic, wish I could have been there.
How am I going to get a copy the Circuit Cellar March edition? I just have to have your article.They don't seem to have it in the print back issues listing.
Heater? Mr "ZiCog"? Methinks he doth protest to much!
Yea, ok, this is a team effort and always has been.
@Chris
Eventually I would like to have several CPUs ... 6809, 6502, Z80, etc. Anybody else interested in this direction? Maybe take it to a different thread?
Great suggestion. Ok, stick the CPU emulator in one cog, with an #IFDEF for the actual hardware external memory system, with then other addons for video, sound, disk storage, and why not have a software configurable retrocomputer?
I'm working right now on displays, have 80x40 on a touchscreen, 6 cogs free. I need one whole day, no alcohol, multiple shots of caffeine and maybe I can glue it to the Zicog. Maybe with a cache xmm for speeds we have not seen before?
I have taken another look at the possibility of using FAT16/32 as the disk format in ZiCog/CPM2.2
The more I look the simpler it seems.
heater do you have the bios/bdos source for Zicog? I think that may be the only part requiring modification, plus of course ftf of the cpm files (which i have working anyway). Any thoughts?
Cluso,
Interesting idea. Basically sounds like you want to throw away the BIOS and BDOS and then write a new BDOS that goes straight to the FAT file system implementing all the BDOS functions http://www.seasip.demon.co.uk/Cpm/bdos.html. I think this has been done in some emulators running on the PC.
Just now I'm far away from the machine with my ZiCog stuff on it. You should be able to find the source files required to build CP/M, including the modified ZiCog BIOS, in the CP/M disk images in most of the ZiCog packages posted here. ZiCog could easily rebuild CP/M on the Propeller. Alternatively get the SIMH Altair package from Peter Schorn from whence it all began http://www.schorn.ch/altair.html
Ok, this has me interested too. pullmoll moved most of the simulation into pasm, but one thing that it needed was a big hub buffer for the video. Move the display out to a touchscreen (which *can* do a 80x40 display) and you save all that hub ram. And if you drop in Kye's SD driver it works out of the box for pretty much every SD card I have tested.
No need necessarily for a Z80 emulation. 8080 was just fine (my preferred CP/M source was Z80 opcodes but only using 8080 ones so essentially 8080 code which is much simpler than Z80, ie Zicog). And if you only use 8080 opcodes we are back to Zicog which is simpler to run.
Keeping with the CP/M philosophy, one always rewrote the disk drivers anyway. Sorry I can't post all mine, they are custom coded for the N8VEM. Head to Peter Schorn's site as heater suggests
I like what you are planning. A few weeks back I finally cracked the CP/M file system code. You probably have too. And it isn't what is in the official textbooks. Basically, the file table is a list of pointers to the data blocks, and if the file is too big, put in multiple file table entries with the same file name.
If you want to check this out, download a clean CP/M 2.2 from the SIMH site, copy just one large (eg >16k) file to the "i" dsk, then examine the i.dsk file using a hex editor. There is something really satisfying about cracking a code like this. What are the chances of us mere mortals ever really understanding fat32 for instance?
If you can crack the "fat" code, you can read and write directly to a SD card file. And that means that Wordstar can read and write a .txt file straight off an SD card. That gives you multiple free text editors for the Propeller chip.
Drac: Yes I worked out the file system for cpm. There are a few 4/8? extents per directory entry. If there are more then another directory entry is added. The sequence number is not necessarily consecutive and this had me stumped for a while until I figured it out. Its to do with the size calcs.
The data heater pointed to I had found, but there was a bit more info there too.
The Fat system is not that complex. Since it seems that the BIOS handles the physical disk code, it seems that I only have to replicate the calls and pass that to spin or pasm. There are relatively few calls and provided I am correct in believing that the code to locate the segments in cpm is hidden from the user by the bios, then this should be quite simple to replace the cpm system with fat16/32. Cpm will not know about sub-directories but I don't think that matters. Later I think we could use disks to substitute for sub-directories. We would just ignore user numbers because fat does not support this.
Now presuming there are no gotchas, then we can use cpm to do any editting we require (wordstar or vedit, etc - take your pick). We would also have supercalc and visicalc, and a database too. Basic, Pascal, etc, etc. And we can switch back and forth between the prop (pasm, spin, C, Forth, Basic or whatever) and Zicog/cpm. In fact, we can keep cpm resident to save even restarting it.
Yes, I am interested in 6502... I didn't find a 6502 emulator for a Propeller, so...
....now I am learning SPIN/PASM by writing a vga driver. It is almost finished - it only needs some debugging (cursor code doesn't work as expected) and cleanup.... then maybe it is time to start working on 6502...
Pik33,
A couple of years back some guys here were working on a 6502 emulator for the Prop. Last I heard they had adopted the same technique of calling multiple atomic functions from addresses squeezed into single dispatch table longs as used in Zicog. A very neat suggetion from Cluso by the way.
I don't know what happened to that effort or how far along it got.
Perhaps you might like to put up a 6502 emulator thread to attract their attention.
Dr A,
An 8080 only emulation for running CP/M is a great idea as it saves having emulation code for instructions that are never used. However the CP/M used in ZiCog,from SIMH Altair, requires some Z80 ops to run the system that rebuilds CP/M. I think it is only the string operations.
There are also some non Digital Research CP/M enhancements that require a Z80 but I'm not inclined to worry about that.
Are you thinking of replicating all the file ones? eg scroll down to function 15, file open. Replace with the fileopen used for an sd card. And return the fields as CP/M expects?
Actually, that list might be a bit long as it includes later versions of CP/M. I'll see if I can find one specific for just CP/M 2.2 as there are only a handful of codes as I recall, and many of them map directly to fsrw/kye sd routines.
Drac: Yes, I believe there are only a few functions to replace. It seems that if you write a new file, the BIOS takes care of adding the entries (havent checked any sources yet).
So the program does not know the format of the directory entries. If this assumption is correct, then it will work with FAT. The 32 byte directory structure and FAT is different in FAT to CPM. Perhaps there may be some programs that do not abide by using the BIOS. If so, I guess I can trap this withing ZiCog to prevent corruption.
If what I now believe to be so, I should be able to remap the BIOS calls directly to Kye's SD drivers. To get just the Editor programs working on the FAT structure would be a fantastic boost to out Prop OS.
I will take a look at your links today Drac. I have some other things I must do also. Thanks.
I tried running Turbo pascal on ramblade and ZiCog. TP uses Z80 instructions, which are not implemented in ZiCog. Attached is my first
try, added/fixed is partial support for SBC HL,xx instruction (partial because not all flags are supported).
I also implemented the EXAF instruction and changed tables for LD A,I, LD A,R and reverse LD I,A, LD R, A to function as NOP.
This are needed by DDTZ (the cp/m Z80 debugger) for trace.
Unfortunately now Turbo pascal hangs when i enter editor mode, so there is more work to be done.
I have fired up TP on a prop, but not done anything with it, but that was using a DracBlade - running Pullmoll's QZ80 - running Pullmoll's Nascom emu - running TP ...
With the memory overheads etc with this setup it only emulates about a 2MHz Z80, where as a Ramblade should give nearer to a 4MHz one, I believe.
Jus for reference, the digital research source for cpm and other things is located here. http://www.cpm.z80.de/source.html Thought it might help since having the real cpm source, might make it easier to emulate it all. hth.
Wow, nice to see someone take interest in ZiCog and welcome to the forum.
I am traveling at the moment so cannot be of much help. I will gladly add any fixes you make to ZiCog.
One suggestion is that there a few instruction groups that are not implemented, bit set/get and such if I remember correctly. These, along with all other not implemeted instructions should be directed to a trap handler in the ZiCog emulation. (I'm not sure if this actually true in the last releases). This way when TP crashes out you might see the instruction that is causing the problem.
Have you run the EXZ80 program on your ZiCog version? It is a thorough instruction set test that did have a couple of failures last time I tried it. It will give clues as to where to look.
By the way ZiCog has always used CP/M 2.2 source code from the SIMH Altair project. The BIOS and boot loader is from there as well, but has been modified. http://www.schorn.ch/altair.html
Ok, so now that I have my human interface board for my quickstart board, I wanted to try this cpm os for the prop.
Unfortunately, I don't see a quick way to locate all the required bits and pieces.
Is there a summary somewhere of what's necessary to download, and where to get them?
I know it won't work as is, since the quickstart isn't a ramblade, but I'm not opposed to modifying code to get it to work, but I can't remember where all the pieces are, even though it was only a month or so ago that I read this entire thread *grumble*.
So, any pointers would be great.
Thanks.
softcon: My latest source is on the ramblade thread at the end and is ZiCog version 173 IIRC. The whole download (for the SD card) is on my bluemagic website IIRC www.cluso.bluemagic.biz
There are other references in my signature. Unfortunately I never had the time to try and get Pullmolls version working on the ramblade.
You will require external ram of some kind to get this running with any of the later forms of the code. As far as I know there were only my TriBlade and RamBlade and the various versions of DrAcula's DracBlade that had ZiCog working - plus a few who built their own various versions of our boards.
If you need help with finding the files then just post here. I am a quite busy with family for Xmas-New Year and apart from that, am working with getting spin running on the P2 emulators. Just post here and I will reply - may take a day or 2.
Or email me cluso at clusos dot com and I can zip the files and send them to you.
Oh, I don't have a ramblade, I had thought the latest version of the code had been written for the ram blades. I have the quickstart board, and the new human interface board for it (sound, vga, ps/2 ports for mouse and keyboard) Everything required to make a nice little stand-alone computer running cp/m. Very cool (if I can make it work) If 173 is the latest, I'll grab it and give it a shot, and see what happens.
I was planning on sifting though all the various versions of ZiCog I have and getting them into some semblance of order whilst away from home over he Christmas break. I even have a repository started for that effort on github. It's time to start thinking about the Prop II version and finishing up those last few missing Z80 instructions. I also want to make a 8080/8085 only version which will save memory space and run CP/M just as well. Now I realize I have left all my ZiCog running hardware behind with no chance to go back and fetch it before New Year. So I won't be able to do any actual development or testing.
You will need some external RAM of some kind and and SD card to get it working. It also requires BST or HomeSpun to compile it as it makes use of #defines to select different hardware options.
There is not much chance of an internet connection out in the forest where I am going but I'll be back on call here after the New Year if I can be of any assistance.
softcon: As heater and I have both said, you will require external ram of some kind (a minimum of 64KB) to store the Z80/cpm code and an SD/microSD card to do the disk storage. We have 8 x 8MB disks mapped into files under FAT16/32 for CPM2.2 execution. The ZiCog emulation will locate these disk files and use them as hard drives A-H under cpm. Most cpm programs run, but not turbo pascal because a few Z80 instructions are not emulated.
The quickstart board already has 64K eeprom, so no problem there. I don't know how much ram it has (only 32K I think, it's not really clear from the text in the various documents, though I'm sure a quick check of the schematics for someone who can read them would answer the question pretty quickly). With the human interface board, I now have sd card abilities too, though I already had one of those anyhow.
Only problem is: I don't actually have an sd card for the reader. Got to go to walmart and fix that.
So, short of adding some external ram (something I want to do anyway) is it possible to run this on my current configuration?
After I get this working, I'll need to add one of the emic2 speech modules, then see what I can do to get me a bit of screen reading support on cp/m, should prove interesting.
Oh, and getting turbo pascal working would be fantastic. Pascal was my second language, and I still use it for quick and dirty hacks that are mostly one-time uses, so having it working on cp/m would be great too.
eeprom will not run fast enough for emulation for zicog. next, it needs to be ram as you might quickly ware out the eeprom. we have not tried any of the cache software afaik.
So, being out of touch with all the external RAM developments that have been going on, what is the easiest way to attach RAM to a Prop now a days?
Being old fashioned and always wanting to save prop pins a single serial RAM device and all DIP would be perfect. I presume we can borrow the cache drivers from propgcc or where ever.
Comments
My main interest from here is a generic "CPU" interface that can be stopped and restarted. It can be single-stepped. The HALT opcode allows for breakpoints. A USB monitor program (takes a COG) would connect to an Eclipse plugin allowing an assembly programmer to edit and debug assembly in the Eclipse graphical interface.
Eventually I would like to have several CPUs ... 6809, 6502, Z80, etc. Anybody else interested in this direction? Maybe take it to a different thread?
Thanks for reading.Boot_joystick - Archive [Date 2012.04.11 Time 17.57].zip
I have the z80 halt instruction returning to a prop os now and that can run the z80 again.
I started on a 6809 emulator a long while back.http://forums.parallax.com/showthread.php?113233-MoCog-A-Motorola-6809-emulator-for-the-Propeller
The ZiCog emulator is only missing a few Z80 opcodes that are never used in the CP/M software I wanted up and running so there was no great pressure to add them. One day I hope to return to that.
The old PropAltair emulator did 8080 perfectly if I remember correctly. At least as far as the EX8080 test program I have is concerned.
Some folks started out on 6502 emulations. Not sure what happened to those efforts.
Then the is th qZ80 emulator from PullMoll http://forums.parallax.com/showthread.php?121579-qZ80-the-third-shot which I believe has all z80 ops working correctly. Sadly he has not shown up here for a long while.
Do you have such an eclipse plugin? That takes debugging Z80 code a billion miles away from debugging ynder CP/M!!
I just checked out the videos of the Expo presentations for Friday. Wow! There you are opening proceedings with Space Invaders and ZiCog gets a mention. Fantastic, wish I could have been there.
How am I going to get a copy the Circuit Cellar March edition? I just have to have your article.They don't seem to have it in the print back issues listing.
*Bows down*
"We are not worthy. We are not worthy"
Heater? Mr "ZiCog"? Methinks he doth protest to much!
Yea, ok, this is a team effort and always has been.
@Chris
Great suggestion. Ok, stick the CPU emulator in one cog, with an #IFDEF for the actual hardware external memory system, with then other addons for video, sound, disk storage, and why not have a software configurable retrocomputer?
I'm working right now on displays, have 80x40 on a touchscreen, 6 cogs free. I need one whole day, no alcohol, multiple shots of caffeine and maybe I can glue it to the Zicog. Maybe with a cache xmm for speeds we have not seen before?
The more I look the simpler it seems.
heater do you have the bios/bdos source for Zicog? I think that may be the only part requiring modification, plus of course ftf of the cpm files (which i have working anyway). Any thoughts?
Interesting idea. Basically sounds like you want to throw away the BIOS and BDOS and then write a new BDOS that goes straight to the FAT file system implementing all the BDOS functions http://www.seasip.demon.co.uk/Cpm/bdos.html. I think this has been done in some emulators running on the PC.
Just now I'm far away from the machine with my ZiCog stuff on it. You should be able to find the source files required to build CP/M, including the modified ZiCog BIOS, in the CP/M disk images in most of the ZiCog packages posted here. ZiCog could easily rebuild CP/M on the Propeller. Alternatively get the SIMH Altair package from Peter Schorn from whence it all began http://www.schorn.ch/altair.html
No need necessarily for a Z80 emulation. 8080 was just fine (my preferred CP/M source was Z80 opcodes but only using 8080 ones so essentially 8080 code which is much simpler than Z80, ie Zicog). And if you only use 8080 opcodes we are back to Zicog which is simpler to run.
Keeping with the CP/M philosophy, one always rewrote the disk drivers anyway. Sorry I can't post all mine, they are custom coded for the N8VEM. Head to Peter Schorn's site as heater suggests
I like what you are planning. A few weeks back I finally cracked the CP/M file system code. You probably have too. And it isn't what is in the official textbooks. Basically, the file table is a list of pointers to the data blocks, and if the file is too big, put in multiple file table entries with the same file name.
If you want to check this out, download a clean CP/M 2.2 from the SIMH site, copy just one large (eg >16k) file to the "i" dsk, then examine the i.dsk file using a hex editor. There is something really satisfying about cracking a code like this. What are the chances of us mere mortals ever really understanding fat32 for instance?
If you can crack the "fat" code, you can read and write directly to a SD card file. And that means that Wordstar can read and write a .txt file straight off an SD card. That gives you multiple free text editors for the Propeller chip.
The data heater pointed to I had found, but there was a bit more info there too.
The Fat system is not that complex. Since it seems that the BIOS handles the physical disk code, it seems that I only have to replicate the calls and pass that to spin or pasm. There are relatively few calls and provided I am correct in believing that the code to locate the segments in cpm is hidden from the user by the bios, then this should be quite simple to replace the cpm system with fat16/32. Cpm will not know about sub-directories but I don't think that matters. Later I think we could use disks to substitute for sub-directories. We would just ignore user numbers because fat does not support this.
Now presuming there are no gotchas, then we can use cpm to do any editting we require (wordstar or vedit, etc - take your pick). We would also have supercalc and visicalc, and a database too. Basic, Pascal, etc, etc. And we can switch back and forth between the prop (pasm, spin, C, Forth, Basic or whatever) and Zicog/cpm. In fact, we can keep cpm resident to save even restarting it.
Yes, I am interested in 6502... I didn't find a 6502 emulator for a Propeller, so...
....now I am learning SPIN/PASM by writing a vga driver. It is almost finished - it only needs some debugging (cursor code doesn't work as expected) and cleanup.... then maybe it is time to start working on 6502...
A couple of years back some guys here were working on a 6502 emulator for the Prop. Last I heard they had adopted the same technique of calling multiple atomic functions from addresses squeezed into single dispatch table longs as used in Zicog. A very neat suggetion from Cluso by the way.
I don't know what happened to that effort or how far along it got.
Perhaps you might like to put up a 6502 emulator thread to attract their attention.
An 8080 only emulation for running CP/M is a great idea as it saves having emulation code for instructions that are never used. However the CP/M used in ZiCog,from SIMH Altair, requires some Z80 ops to run the system that rebuilds CP/M. I think it is only the string operations.
There are also some non Digital Research CP/M enhancements that require a Z80 but I'm not inclined to worry about that.
Are you thinking of replicating all the file ones? eg scroll down to function 15, file open. Replace with the fileopen used for an sd card. And return the fields as CP/M expects?
Actually, that list might be a bit long as it includes later versions of CP/M. I'll see if I can find one specific for just CP/M 2.2 as there are only a handful of codes as I recall, and many of them map directly to fsrw/kye sd routines.
This one is a bit easier to follow http://members.iinet.net.au/~daveb/cpm/bdosfunc.html
Scroll down and I think for CP/M 2.2 you can stop at function 40.
I must say, this would be a pretty cool thing to do. Did you find the source code?
So the program does not know the format of the directory entries. If this assumption is correct, then it will work with FAT. The 32 byte directory structure and FAT is different in FAT to CPM. Perhaps there may be some programs that do not abide by using the BIOS. If so, I guess I can trap this withing ZiCog to prevent corruption.
If what I now believe to be so, I should be able to remap the BIOS calls directly to Kye's SD drivers. To get just the Editor programs working on the FAT structure would be a fantastic boost to out Prop OS.
I will take a look at your links today Drac. I have some other things I must do also. Thanks.
try, added/fixed is partial support for SBC HL,xx instruction (partial because not all flags are supported).
I also implemented the EXAF instruction and changed tables for LD A,I, LD A,R and reverse LD I,A, LD R, A to function as NOP.
This are needed by DDTZ (the cp/m Z80 debugger) for trace.
Unfortunately now Turbo pascal hangs when i enter editor mode, so there is more work to be done.
With the memory overheads etc with this setup it only emulates about a 2MHz Z80, where as a Ramblade should give nearer to a 4MHz one, I believe.
Wow, nice to see someone take interest in ZiCog and welcome to the forum.
I am traveling at the moment so cannot be of much help. I will gladly add any fixes you make to ZiCog.
One suggestion is that there a few instruction groups that are not implemented, bit set/get and such if I remember correctly. These, along with all other not implemeted instructions should be directed to a trap handler in the ZiCog emulation. (I'm not sure if this actually true in the last releases). This way when TP crashes out you might see the instruction that is causing the problem.
Have you run the EXZ80 program on your ZiCog version? It is a thorough instruction set test that did have a couple of failures last time I tried it. It will give clues as to where to look.
By the way ZiCog has always used CP/M 2.2 source code from the SIMH Altair project. The BIOS and boot loader is from there as well, but has been modified.
http://www.schorn.ch/altair.html
Unfortunately, I don't see a quick way to locate all the required bits and pieces.
Is there a summary somewhere of what's necessary to download, and where to get them?
I know it won't work as is, since the quickstart isn't a ramblade, but I'm not opposed to modifying code to get it to work, but I can't remember where all the pieces are, even though it was only a month or so ago that I read this entire thread *grumble*.
So, any pointers would be great.
Thanks.
There are other references in my signature. Unfortunately I never had the time to try and get Pullmolls version working on the ramblade.
You will require external ram of some kind to get this running with any of the later forms of the code. As far as I know there were only my TriBlade and RamBlade and the various versions of DrAcula's DracBlade that had ZiCog working - plus a few who built their own various versions of our boards.
If you need help with finding the files then just post here. I am a quite busy with family for Xmas-New Year and apart from that, am working with getting spin running on the P2 emulators. Just post here and I will reply - may take a day or 2.
Or email me cluso at clusos dot com and I can zip the files and send them to you.
Sorry for not replying earlier.
I was planning on sifting though all the various versions of ZiCog I have and getting them into some semblance of order whilst away from home over he Christmas break. I even have a repository started for that effort on github. It's time to start thinking about the Prop II version and finishing up those last few missing Z80 instructions. I also want to make a 8080/8085 only version which will save memory space and run CP/M just as well. Now I realize I have left all my ZiCog running hardware behind with no chance to go back and fetch it before New Year. So I won't be able to do any actual development or testing.
You will need some external RAM of some kind and and SD card to get it working. It also requires BST or HomeSpun to compile it as it makes use of #defines to select different hardware options.
There is not much chance of an internet connection out in the forest where I am going but I'll be back on call here after the New Year if I can be of any assistance.
Only problem is: I don't actually have an sd card for the reader.
So, short of adding some external ram (something I want to do anyway) is it possible to run this on my current configuration?
After I get this working, I'll need to add one of the emic2 speech modules, then see what I can do to get me a bit of screen reading support on cp/m, should prove interesting.
Oh, and getting turbo pascal working would be fantastic. Pascal was my second language, and I still use it for quick and dirty hacks that are mostly one-time uses, so having it working on cp/m would be great too.
Being old fashioned and always wanting to save prop pins a single serial RAM device and all DIP would be perfect. I presume we can borrow the cache drivers from propgcc or where ever.