While you are testing, any chance you could take a couple of photos, one of the top side and one of the solder side of the board. I might be able to see something wrong. Thx.
For the proptool/BST to recognise the propeller there are only a few components being used. Just the prop chip, xtal, max232 and the reset transistor.
The pulse on the transistor is pretty brief and you might need a CRO to see it so maybe leave that test till later.
The xtal and propeller look like they are all ok. Just once or twice I have had pins bent under the socket, so maybe pull the chips out and check the pins and put them back in again.
The max232 - you should have 9V on pin 2, and minus 9V on 6, 7 and 14.
Do you get the green led flashing briefly when you try to download a program or do an F7 test?
Just occasionally I've had to resort to doing a loopback test on RS232. Join pins 2 and 3 inside the male plug with a crocodile lead, and use any terminal program and if you type something on the keyboard on the PC it should appear on the screen if 2 and 3 are joined, and not if they are not joined.
The xtal and propeller look like they are all ok. Just once or twice I have had pins bent under the socket, so maybe pull the chips out and check the pins and put them back in again.
Ok, I'll do that. Update: no bent pins that I could find.
Do you get the green led flashing briefly when you try to download a program or do an F7 test?
Not with bst / my Linux machine, but with Windows / Proptool; yes, I get a flash of green.
(the bst thing might be a problem with Linux 64-bit machines)
Just occasionally I've had to resort to doing a loopback test on RS232. Join pins 2 and 3 inside the male plug with a crocodile lead, and use any terminal program and if you type something on the keyboard on the PC it should appear on the screen if 2 and 3 are joined, and not if they are not joined.
The loopback test confirms that the usb-to-serial adapter is working.
If you have windows and the proptool let's test with that.
Ok, when you press F7, the red and the green leds should flash. The green led is data to the prop, and the red is data back to the PC.
You are only getting a green flash.
First, let's test things right at the propeller chip. If you have done the loopback test then this should be easy. Take the propeller chip out of the socket and temporarily join pins 39 and 40 using a little bit of wire poked into the sockets.
If you now do the loopback test you should get the red and green leds flashing. That will test the max232 chip.
If that works, then I would be suspicious of the reset transistor. Put the propeller chip back in and measure the volts on pin 11 and you should get about 3.2V. If you now find R20 (10k) and join the top of that resistor (next to the R) to ground, this should pull the reset line to 0V. That will test if the transistor is working.
First, let's test things right at the propeller chip. If you have done the loopback test then this should be easy. Take the propeller chip out of the socket and temporarily join pins 39 and 40 using a little bit of wire poked into the sockets.
If you now do the loopback test you should get the red and green leds flashing. That will test the max232 chip.
I don't know how to do the loopback test with the Windows tools, so I did it with Linux. When I tried cu -s 115200 -l ttyUSB0 I got only garbage characters back. And only the green LED blinks.Ok, that looks like a speed problem. So I tried cu -s 9600 -l ttyUSB0 instead. Now I get the correct characters back, and both the red and the green LEDs blinks.
Interesting.
If that works, then I would be suspicious of the reset transistor. Put the propeller chip back in and measure the volts on pin 11 and you should get about 3.2V. If you now find R20 (10k) and join the top of that resistor (next to the R) to ground, this should pull the reset line to 0V. That will test if the transistor is working.
Well, when I do that, pin 11 goes to 0.6 V. Is that close enough to zero?
Update: I just exchanged the provided usb-to-serial adapter with another I had lying around (a generic pl-2303 based one), and when I now press F7 in proptool (Windows), it searches for a bit and then informs me: "Propeller chip version 1 found on COM8." Nice! :-D
Success report: I am finally running KyeDOS on my DracBlade, with a ps/2 keyboard and output via the serial port. It turns out that bstc works under Linux (for compiling programs at least), and I used Loader.py to upload KyeDOS to the DracBlade. Now it is time to get CP/M running.
Well I can't explain why one USB to serial device works and another does not, especially when the same one works on my PC?!!
Anyway, great to hear it works.
Ok, on to CP/M. Attached are the files and the disk images. Put the disk images on a sd card. Now I'm not 100% sure whether this is fat32 or fat16 so try with the sd card as it is first but if it does not work, reformat it for fat16.
The main program is "cpm.spin" and in there are a whole lot of settings. I am not sure if this one is set up for vga or tv - hopefully you can work out what to change but if not then let me know.
I got the files, unpacked the cp/m archive and tried compiling it with bstc:
tingo@kg-u35jc:~/work/drac/cpm$ bstc -b cpm.spin
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object cpm
cpm(76,9) Error : Symbol SI is already defined!
SI = 23
________^
cpm - Error at (128,1) Expected Object definition
#ifdef CPU_Z80
^
Compiled 116 Lines of Code in 0.002 Seconds
(I also tried bst, but got the same error there when compiling cpm.spin)
tingo@kg-u35jc:~/work/drac/cpm$ bstc -b -O xr cpm.spin
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object cpm
Loading Object io
Loading Object fatfs
Loading Object spi_warp
Loading Object pcFullDuplexSerial2FC
Loading Object Keyboard
Loading Object VGA_HiRes_Text
Loading Object vt100_mono
Loading Object qz80
Program size is 31168 longs
Compiled 8069 Lines of Code in 0.583 Seconds
a few adjustments now, a recompile, and I'm ready to test it.
Ok, that cp/m zip I posted is for a VGA version. So you might need to get a display working rather than using the serial port. Also, that version is not outputting anything to the serial port (there were versions of cp/m that did work through the serial port but I think they were earlier versions). Have you got a spare vga monitor you could use?
Addit - just occasionally cp/m won't boot the first time. And at bootup, you should get the red led briefly flashing on the serial port at startup, and also the 'diag' led should flash as it accesses the sd card.
Ok, that cp/m zip I posted is for a VGA version. So you might need to get a display working rather than using the serial port. Also, that version is not outputting anything to the serial port (there were versions of cp/m that did work through the serial port but I think they were earlier versions). Have you got a spare vga monitor you could use?
I changed it before compiling it again (commented out the #define USER0_PS2_VGA). Shouldn't that give me a serial output version?
I don't have a spare VGA monitor now (will get one next week, hopefully)
Oh, and this version of cp/m outputs *something* to the serial port:
Addit - just occasionally cp/m won't boot the first time. And at bootup, you should get the red led briefly flashing on the serial port at startup, and also the 'diag' led should flash as it accesses the sd card.
Ah, it may not be 115200, and it might be using one of the spin serial drivers that has trouble at that speed. Try 38400 baud. I think you are getting close...
Addit - in the file "io", I think it is set for 38400 for port 1 and 9600 for the other serial port. So try changing the rate in your terminal program first, and if it works, try increasing the speed.
Second Addit: I just checked the time in Oslo - have you been up all night with this?
Ah, it may not be 115200, and it might be using one of the spin serial drivers that has trouble at that speed. Try 38400 baud. I think you are getting close...
Yes, that was it (for some reason it didn't like that I disconnected cu and connected again; I still got garbage, so I did the startup "blind", by typing cpm and "enter" on the ps/2 keyboard)
tingo@kg-u35jc:~$ cu -s 38400 -l /dev/ttyUSB0
Connected.
�������������������������������������
SIO initialized, 5 cogs free.
KBD initialized, 4 cogs free.
VGA initialized, 2 cogs free.
qZ80 I/O starting...
Volume serial #E3E6-DA22, label NO NAME
BOOT.DSK, sector 01F7C0, size 256, 2011-10-09 02:23:42
A.DSK, sector 0237E0, size 32.0MB, 2011-10-09 02:23:42 contiguous - okay.
B.DSK, sector 01F7E0, size 8.0MB, 2011-10-09 02:23:42 contiguous - okay.
C.DSK, sector 01B7C0, size 8.0MB, 2011-10-09 02:23:42 contiguous - okay.
I/O initialized, 1 cogs free.
VT100 initialized, 0 cogs free.
Going to start qz80. Goodbye Spin!
64K CP/M Version 2.2 (qZ80, BIOS V1.27_Zi04, 3 HD, 21-Apr-20
SuperSUB V1.1
Submit file not found error on line number: 0
A>
Addit - in the file "io", I think it is set for 38400 for port 1 and 9600 for the other serial port. So try changing the rate in your terminal program first, and if it works, try increasing the speed.
You should be able to run wordstar WS and MBASIC amongst other things - they are on disk A.
The error with the submit file is so you can put a file called AUTOEXEC.SUB on the drive and it will run whatever is in that file on bootup. And you can create that file from within wordstar.
Just for the record - I also have CP/M running on my Dracblade. I use a VGA monitor.
I had problems getting the serial USB cable working, only got the green flash. But I've only tried with one computer (my 64-bit Linux desktop, I've got an old 32-bit Linux laptop which I'm using mostly with my QuickStart, haven't tested the Dracblade against it). It works with the Propeller usb-serial though, so I'm OK.
The CP/M doesn't seem fast though :-) - or at least it's not updating the screen particularly fast.. I have problems remembering how fast CP/M would run back in the old days (early eighties), maybe it was that slow, or maybe not. I have another system with a real Z80, it's much faster.. but it's also a 16 MHz Z80, something we could only dream about back in the day.
I've spread myself over too many hobby projects lately, so my testing of CP/M on the Dracblade has been a bit spotty! :-) I have to come back to it later. I also had a stop for a while until I figured out the communication problem.
Toby is right, it is running at about 2Mhz on this board. But it can go faster. That board has three latches so for every byte read, a latch has to change. There are solutions that use more propeller pins and less latches. Cluso has a design that has no latches - I wonder how fast he got that running?
This design uses 12 prop pins for external ram, and by going to 16 pins it means that ram can be read in blocks of 256 bytes with no latch changes which ought to be faster.
Ultimately I am finding Catalina more satisfying than CP/M. CP/M can certainly run C programs (and even compile them) but they are limited in size to about 40k, whereas Catalina seems to have an almost unlimited program size. Plus Catalina is faster.
Toby is right, it is running at about 2Mhz on this board. But it can go faster. That board has three latches so for every byte read, a latch has to change. There are solutions that use more propeller pins and less latches. Cluso has a design that has no latches - I wonder how fast he got that running?
This design uses 12 prop pins for external ram, and by going to 16 pins it means that ram can be read in blocks of 256 bytes with no latch changes which ought to be faster.
Ultimately I am finding Catalina more satisfying than CP/M. CP/M can certainly run C programs (and even compile them) but they are limited in size to about 40k, whereas Catalina seems to have an almost unlimited program size. Plus Catalina is faster.
Dr_Acula
is the XMEM access code in qz80 the same found in Catalina XMEM driver for DracBlade?
Thanks AntoineDoinel, if you can make it run faster that would be great!
I must say I haven't looked at the code for a year now, but I am going to be porting things over from the 3 latch design to a 2 latch design soon, so advice from all the pasm experts will be gratefully received when I get to the coding stage.
As I recall, I think there were about 20 pasm instructions just to get one byte out of memory which is slow.
Another benchmark might be heater's original 8080 emulation which didn't try to give you the full 64k and he managed to get that working out of hub with no external ram. So I'm wondering if you could get a speed increase by, say, splitting the 64k into four blocks of 16k, and one block is in hub which is the block where the main program is, and then only read bytes from external ram if they are outside that block. The hard part is working out an algorithm that says 'the main program has now jumped out of this block, so is it better to read in a whole 16k block now or to leave it for a while in case this is a jump to a small subroutine'.
You could keep track of how many accesses are happening to each block and have a rolling average and load in the block that is being accessed the most.
I'm not an expert at caching algorithms though. I am hoping that with the two latch solution, you can read in 256 bytes at about 6 pasm instructions per byte and get a speedup that way. I suspect that one is better having lots of small caches rather than one large one. With a two latch solution, the caches would naturally be 256 bytes, and then you need a little cache access array to keep track of how many hits each one is getting. Move into hub the ones that are getting the most.
While I am pondering crazy things, one thing I have wondered is whether one could escape the 16 bit limitation of CP/M and the Z80 by emulating all the registers (including the Program Counter) as longs rather than as words. But probably no point given no-one much codes in Z80 any more. I suspect this was the stream of consciousness that heater followed that took him to Zog (which has a much leaner RISC instruction set compared to the Z80).
I also have wondered where Juergen has gone. His last posting said something about moving onto another project.
I am so grateful to Juergen for popping up and doing the QZ80 code, this let me get the blessed Nascom trundling along again. Of course having craved for it and then getting it I havent done that much with it, but I won't be leaving this one in a shed at a place I am "persona non gratis".
He was just so fast at code revisions, five minutes of his time is a year's worth to me!
With Dr_A's loading code into COGs and then recovering the HUB RAM back again I was wondering about using the recovered HUB as a cache (or even as some RAM for a bolted on Z80).
With Dr_A's loading code into COGs and then recovering the HUB RAM back again I was wondering about using the recovered HUB as a cache (or even as some RAM for a bolted on Z80).
Ah, ok, well that has me really thinking. Juergen took the propeller chip to new levels, as epitomised by his friendly message only a few lines into the code
io.str(string("Going to start qz80. Goodbye Spin!",13,10))
First thing he did was to load up all the cogs. Then load the spin cog with new pasm code and stop spin. Then he did everything in pasm.
Bit I still think it can be faster. Here we have an 80Mhz cog with an emulation running at 2Mhz.
So let's take Juergen's idea of a Propeller stripped of spin and running in its purest form - 8 cogs running pasm and hub all free. We can think of several sorts of caches. Level 1 exists in a cog. Level 2 exists in hub ram. Level 3 exists in external ram. And maybe you could add level 4, in an SD card.
So, we take a 64k memory space for CP/M and put that in hub. 50% probability of a cache hit. If there is a miss, read the block from external ram. If you use "Least Recently Used" algorithm, then the block that contains the current program counter will end up always at the top of the list so always in the cache. And mostly the memory and accesses to data will work, so there will be a much greater than 50% chance of a cache hit.
Let's do an emulation purely in one cog. So there would be a speedup from LMM to pure cog code. Heater got an 8080 in one cog so it is not crazy, especially since CP/M and the vast majority of CP/M programs only ever used 8080 opcodes.
The 8080 registers are in the cog, not in hub, so that gives a speedup, as I believe rdlong and wrlong need to wait for that cog to come around.
Now let's take the blocks in hub ram (maybe they are 256 bytes, maybe 1k) and then let's take the cache concept further and create a cache in the cog. Maybe only 16 x16 bytes. Still a fairly good chance of a hit, especially if you are emulating a program loop.
So, you request a byte, and if it is in cog, read it directly, and if not, read from hub, and if not in hub, read from ram.
Can you take this concept further?
How about we not just cache the 64k of memory, but we cache the code needed to emulate the instructions?
Code is of a fixed block size. I believe code is also relocatable, ie you can move it around within a cog and it will still work. Self modifying cog code has been done before. Some instructions might only be a few pasm instructions anyway. Z80/8080 opcodes start with bytes 0-255 so you can have a lookup table - is the instruction in the cache? yes, then get its location and do a jump. If no, then read it in from hub. Use the LRU algorithm and fairly quickly the popular instructions will stay in the cog cache.
Need some lookup tables and that will consume ?512 bytes. Then perhaps devote half the cog code to cache and half to code. The half for cache might be divided into half for ram cache and half for instruction cache. Does that leave enough for a reasonable sized cache?
I don't know if it would work, but in a best case scenario, a Z80 instruction exists in the cog, and so does the ram data it might access and it might be possible to greatly speed up the emulation.
I need to think more about caching - it raises some intriguing possibilities.
Ok, on to CP/M. Attached are the files and the disk images. Put the disk images on a sd card. Now I'm not 100% sure whether this is fat32 or fat16 so try with the sd card as it is first but if it does not work, reformat it for fat16.
@Dr_A,
re. Disk_images.zip - what is the format of the A/B/C disk image files? I would like to access the .dsk files with my desktop computer with the help of 'cpmtools', but to do that I would need to know sector length, number of tracks, sectors/track, max. dir elements, skew factor.. if you have 'cpmtools' installed on some *nix box I'm referring to the kind of definitions found in /etc/cpmtools/diskdefs
Maybe this has been said in some other post, but I'm unable to find it - this thread is quite long..
If you scroll down a bit there is CP/M 2.2. On that are floppy disk images and a hard disk image i.dsk. The file is the same as i.dsk
The history behind this is that we initially started with the floppy disk images but they proved to be a bit small and inconvenient at under 1 meg. So we moved over to the 8 meg hard disk images which also have a simpler format.
If you are in the simh simulation and you find a file on, say, disk A, that you like, then copy it to disk I with PIP (yeah, you have to learn a bit of CP/M!). Then copy disk I onto the sd card. You can move files back to the simh that way as well. The simh has programs R.COM and W.COM that move files from the simh to the local PC directory.
There are other ways to transfer files as well, like xmodem.
We never got R.COM and W.COM to work on the propeller - it is one of those things that sounds easy but is really hard. But the method above works well, especially as you can copy an entire disk with PIP *.*
So you don't need to know about sector lengths etc.
If you want to make lots of disk images, take a copy of that blank I.DSK file and rename it to BLANK.DSK (or whatever) before you copy anything onto it, and then you have an unlimited number of blank disks.
First thing I did when I got this working was grab every disk on the simh site. (These disks cost real money when I was a kid!)
I prefer to use the cpmtools method instead of PIP, because I have files from way back in the past that I wish to copy to the disk image(s). I can't PIP them from an existing simh image. And working on the image is much simpler than setting up an xmodem connection, at least to start with.
Comments
http://picasaweb.google.com/108051455536264011267/DracBlade?authuser=0&authkey=Gv1sRgCJ_Oh9zy4MyflAE&feat=directlink
(this is the first time I'm using Google's picture service, so be gentle if something is wrong).
The pulse on the transistor is pretty brief and you might need a CRO to see it so maybe leave that test till later.
The xtal and propeller look like they are all ok. Just once or twice I have had pins bent under the socket, so maybe pull the chips out and check the pins and put them back in again.
The max232 - you should have 9V on pin 2, and minus 9V on 6, 7 and 14.
Do you get the green led flashing briefly when you try to download a program or do an F7 test?
Just occasionally I've had to resort to doing a loopback test on RS232. Join pins 2 and 3 inside the male plug with a crocodile lead, and use any terminal program and if you type something on the keyboard on the PC it should appear on the screen if 2 and 3 are joined, and not if they are not joined.
Do you have any other propeller boards?
Update: no bent pins that I could find.
Check (Yes, that's what I have)
Not with bst / my Linux machine, but with Windows / Proptool; yes, I get a flash of green.
(the bst thing might be a problem with Linux 64-bit machines)
The loopback test confirms that the usb-to-serial adapter is working.
Unfortunately, no, I don't.
If you have windows and the proptool let's test with that.
Ok, when you press F7, the red and the green leds should flash. The green led is data to the prop, and the red is data back to the PC.
You are only getting a green flash.
First, let's test things right at the propeller chip. If you have done the loopback test then this should be easy. Take the propeller chip out of the socket and temporarily join pins 39 and 40 using a little bit of wire poked into the sockets.
If you now do the loopback test you should get the red and green leds flashing. That will test the max232 chip.
If that works, then I would be suspicious of the reset transistor. Put the propeller chip back in and measure the volts on pin 11 and you should get about 3.2V. If you now find R20 (10k) and join the top of that resistor (next to the R) to ground, this should pull the reset line to 0V. That will test if the transistor is working.
cu -s 115200 -l ttyUSB0 I got only garbage characters back. And only the green LED blinks.Ok, that looks like a speed problem. So I tried cu -s 9600 -l ttyUSB0 instead. Now I get the correct characters back, and both the red and the green LEDs blinks.
Interesting.
Anyway, great to hear it works.
Ok, on to CP/M. Attached are the files and the disk images. Put the disk images on a sd card. Now I'm not 100% sure whether this is fat32 or fat16 so try with the sd card as it is first but if it does not work, reformat it for fat16.
The main program is "cpm.spin" and in there are a whole lot of settings. I am not sure if this one is set up for vga or tv - hopefully you can work out what to change but if not then let me know.
tingo@kg-u35jc:~/work/drac/cpm$ bstc -b cpm.spin Found a USB Serial Device Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved Compiled for i386 Linux at 08:17:46 on 2009/07/20 Loading Object cpm cpm(76,9) Error : Symbol SI is already defined! SI = 23 ________^ cpm - Error at (128,1) Expected Object definition #ifdef CPU_Z80 ^ Compiled 116 Lines of Code in 0.002 Seconds(I also tried bst, but got the same error there when compiling cpm.spin)Addit - just occasionally cp/m won't boot the first time. And at bootup, you should get the red led briefly flashing on the serial port at startup, and also the 'diag' led should flash as it accesses the sd card.
I don't have a spare VGA monitor now (will get one next week, hopefully)
Oh, and this version of cp/m outputs *something* to the serial port: (snipped for brevity)
It looks like it is at the wrong serial speed. Isn't this cp/m configured for 115200 bps?
Yes, the leds flash.
Addit - in the file "io", I think it is set for 38400 for port 1 and 9600 for the other serial port. So try changing the rate in your terminal program first, and if it works, try increasing the speed.
Second Addit: I just checked the time in Oslo - have you been up all night with this?
Ok, I'm busted :-)
(It is nice to have a weekend just for myself now and then)
You should be able to run wordstar WS and MBASIC amongst other things - they are on disk A.
The error with the submit file is so you can put a file called AUTOEXEC.SUB on the drive and it will run whatever is in that file on bootup. And you can create that file from within wordstar.
To all involved: well done, this is very cool!
I had problems getting the serial USB cable working, only got the green flash. But I've only tried with one computer (my 64-bit Linux desktop, I've got an old 32-bit Linux laptop which I'm using mostly with my QuickStart, haven't tested the Dracblade against it). It works with the Propeller usb-serial though, so I'm OK.
The CP/M doesn't seem fast though :-) - or at least it's not updating the screen particularly fast.. I have problems remembering how fast CP/M would run back in the old days (early eighties), maybe it was that slow, or maybe not. I have another system with a real Z80, it's much faster.. but it's also a 16 MHz Z80, something we could only dream about back in the day.
I've spread myself over too many hobby projects lately, so my testing of CP/M on the Dracblade has been a bit spotty! :-) I have to come back to it later. I also had a stop for a while until I figured out the communication problem.
I also plan to test Catalina on this Dracblade.
-Tor
This design uses 12 prop pins for external ram, and by going to 16 pins it means that ram can be read in blocks of 256 bytes with no latch changes which ought to be faster.
Ultimately I am finding Catalina more satisfying than CP/M. CP/M can certainly run C programs (and even compile them) but they are limited in size to about 40k, whereas Catalina seems to have an almost unlimited program size. Plus Catalina is faster.
Dr_Acula
is the XMEM access code in qz80 the same found in Catalina XMEM driver for DracBlade?
Yes it is.
I trimmed quite a few instruction from access code in DracBlade_XMM.inc (for Catalina ver 3.2).
Should be a little faster, but it remains to be seen if those optimization are applicable to all DracBlades (my selfmade board had 20ns chips IIRC).
However it seems unlikely to me that Juergen left anything optimizable by mere mortals, non-Kuroneko earthlings
BTW has anyone heard from him lately?
I must say I haven't looked at the code for a year now, but I am going to be porting things over from the 3 latch design to a 2 latch design soon, so advice from all the pasm experts will be gratefully received when I get to the coding stage.
As I recall, I think there were about 20 pasm instructions just to get one byte out of memory which is slow.
Another benchmark might be heater's original 8080 emulation which didn't try to give you the full 64k and he managed to get that working out of hub with no external ram. So I'm wondering if you could get a speed increase by, say, splitting the 64k into four blocks of 16k, and one block is in hub which is the block where the main program is, and then only read bytes from external ram if they are outside that block. The hard part is working out an algorithm that says 'the main program has now jumped out of this block, so is it better to read in a whole 16k block now or to leave it for a while in case this is a jump to a small subroutine'.
You could keep track of how many accesses are happening to each block and have a rolling average and load in the block that is being accessed the most.
I'm not an expert at caching algorithms though. I am hoping that with the two latch solution, you can read in 256 bytes at about 6 pasm instructions per byte and get a speedup that way. I suspect that one is better having lots of small caches rather than one large one. With a two latch solution, the caches would naturally be 256 bytes, and then you need a little cache access array to keep track of how many hits each one is getting. Move into hub the ones that are getting the most.
While I am pondering crazy things, one thing I have wondered is whether one could escape the 16 bit limitation of CP/M and the Z80 by emulating all the registers (including the Program Counter) as longs rather than as words. But probably no point given no-one much codes in Z80 any more. I suspect this was the stream of consciousness that heater followed that took him to Zog (which has a much leaner RISC instruction set compared to the Z80).
I also have wondered where Juergen has gone. His last posting said something about moving onto another project.
He was just so fast at code revisions, five minutes of his time is a year's worth to me!
With Dr_A's loading code into COGs and then recovering the HUB RAM back again I was wondering about using the recovered HUB as a cache (or even as some RAM for a bolted on Z80).
Ah, ok, well that has me really thinking. Juergen took the propeller chip to new levels, as epitomised by his friendly message only a few lines into the code
io.str(string("Going to start qz80. Goodbye Spin!",13,10))First thing he did was to load up all the cogs. Then load the spin cog with new pasm code and stop spin. Then he did everything in pasm.Bit I still think it can be faster. Here we have an 80Mhz cog with an emulation running at 2Mhz.
First thing, I took a look at caching http://en.wikipedia.org/wiki/Cache_algorithms and in particular CPU caching http://en.wikipedia.org/wiki/CPU_cache
So let's take Juergen's idea of a Propeller stripped of spin and running in its purest form - 8 cogs running pasm and hub all free. We can think of several sorts of caches. Level 1 exists in a cog. Level 2 exists in hub ram. Level 3 exists in external ram. And maybe you could add level 4, in an SD card.
So, we take a 64k memory space for CP/M and put that in hub. 50% probability of a cache hit. If there is a miss, read the block from external ram. If you use "Least Recently Used" algorithm, then the block that contains the current program counter will end up always at the top of the list so always in the cache. And mostly the memory and accesses to data will work, so there will be a much greater than 50% chance of a cache hit.
Let's do an emulation purely in one cog. So there would be a speedup from LMM to pure cog code. Heater got an 8080 in one cog so it is not crazy, especially since CP/M and the vast majority of CP/M programs only ever used 8080 opcodes.
The 8080 registers are in the cog, not in hub, so that gives a speedup, as I believe rdlong and wrlong need to wait for that cog to come around.
Now let's take the blocks in hub ram (maybe they are 256 bytes, maybe 1k) and then let's take the cache concept further and create a cache in the cog. Maybe only 16 x16 bytes. Still a fairly good chance of a hit, especially if you are emulating a program loop.
So, you request a byte, and if it is in cog, read it directly, and if not, read from hub, and if not in hub, read from ram.
Can you take this concept further?
How about we not just cache the 64k of memory, but we cache the code needed to emulate the instructions?
Code is of a fixed block size. I believe code is also relocatable, ie you can move it around within a cog and it will still work. Self modifying cog code has been done before. Some instructions might only be a few pasm instructions anyway. Z80/8080 opcodes start with bytes 0-255 so you can have a lookup table - is the instruction in the cache? yes, then get its location and do a jump. If no, then read it in from hub. Use the LRU algorithm and fairly quickly the popular instructions will stay in the cog cache.
Need some lookup tables and that will consume ?512 bytes. Then perhaps devote half the cog code to cache and half to code. The half for cache might be divided into half for ram cache and half for instruction cache. Does that leave enough for a reasonable sized cache?
I don't know if it would work, but in a best case scenario, a Z80 instruction exists in the cog, and so does the ram data it might access and it might be possible to greatly speed up the emulation.
I need to think more about caching - it raises some intriguing possibilities.
@Dr_A,
re. Disk_images.zip - what is the format of the A/B/C disk image files? I would like to access the .dsk files with my desktop computer with the help of 'cpmtools', but to do that I would need to know sector length, number of tracks, sectors/track, max. dir elements, skew factor.. if you have 'cpmtools' installed on some *nix box I'm referring to the kind of definitions found in /etc/cpmtools/diskdefs
Maybe this has been said in some other post, but I'm unable to find it - this thread is quite long..
-Tor
If you scroll down a bit there is CP/M 2.2. On that are floppy disk images and a hard disk image i.dsk. The file is the same as i.dsk
The history behind this is that we initially started with the floppy disk images but they proved to be a bit small and inconvenient at under 1 meg. So we moved over to the 8 meg hard disk images which also have a simpler format.
If you are in the simh simulation and you find a file on, say, disk A, that you like, then copy it to disk I with PIP (yeah, you have to learn a bit of CP/M!). Then copy disk I onto the sd card. You can move files back to the simh that way as well. The simh has programs R.COM and W.COM that move files from the simh to the local PC directory.
There are other ways to transfer files as well, like xmodem.
We never got R.COM and W.COM to work on the propeller - it is one of those things that sounds easy but is really hard. But the method above works well, especially as you can copy an entire disk with PIP *.*
So you don't need to know about sector lengths etc.
If you want to make lots of disk images, take a copy of that blank I.DSK file and rename it to BLANK.DSK (or whatever) before you copy anything onto it, and then you have an unlimited number of blank disks.
First thing I did when I got this working was grab every disk on the simh site. (These disks cost real money when I was a kid!)
Let me know if you have any problems.
I prefer to use the cpmtools method instead of PIP, because I have files from way back in the past that I wish to copy to the disk image(s). I can't PIP them from an existing simh image. And working on the image is much simpler than setting up an xmodem connection, at least to start with.
-Tor