Congratulations on this accomplishment! I am really excited and looking forward to seeing this work.
This, the ROM decrypting contest, the Spin interpreter source---man, I need to take a vacation
just to have time to play with the Prop.
I have not found the time to do any work on the 8085 emulator as promised. So here is my latest effort.
Have to dash just now so no time for instructions. Perhaps later today.
If any one wants to cast an eye over it I would be glad to hear any comments suggestions etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Attached is version 1.2 of my 8085 simulator for the Propeller which now runs CP/M as far as the command prompt and accepts keyboard input. I have no disk image in my SD card at the moment so that's about it. All console I/O is via PropTerminal as this should be usable by everyone with no TV or spare VGA screen around (Like myself).
Also attached is a screen capture of the CPM boot messages as far as the boot prompt and another image showing what happens when a command is typed. Not much yet but I just had to show someone !
A few notes at random:
1. altair_sim.spin is the top level file which just starts the simulator components and then hangs in a repeat.
2. altair_cpu is the actual 8085 CPU emulator. It's start methods single parameter is a pointer to two longs. First is the address of the 8085's memory second is a pointer to three longs used to communicate with the IO subsystem altair_io for "in" and "out" instructions.
3. altair_mem.spin defines the 8085's memory area (ram_8085) and fills it with 8085 code. Currently this is a jump to the CPM's bios at address zero. Then a jump to CPM's bdos at address 5. Then we pad with zeros untill 100 HEX which is whre CPM loads user programs (Transient Program Area or TPA as it's called). The TPA is loaded with a CPM program from a file p.com. Following the TPA the command processor is loaded from ccp.com, the basic disk operating system is loaded from bdos.com and the bios is loaded from cbiosx.com
These .com files have all been assembled using the altair simulator I linked to earlier running on Windows XP. p.com is actually my instruction set test program which for some reason does not work just now. No matter it's not used but it must be the right length to cause the following files to be loaded at the correct addresses. All these files configured and assembled for a system with 20K of RAM. Seems we could go to 24K.
4. alatair_ios.spin is to take care of the altair console input/output and disk drives and any other things that we may want to drive via "in" and "out" instructions. Currently IO address 0 is used to drive the LEDs on a propeller demo board. Communication with the emulator cog for IN and OUT instructions is done via three longs in ctl_addr. Console IO is directed to PC_tv and PC_keyboard as stated.
An SD card is used for the disks. There is no disk image to boot yet but no worries the Prop has already got all the CPM files in its memory as described. Also means we don't need any have any ROM boot loader code yet. I have done a little testing on the sector read/write but all this is under construction at the moment.
Please someone look this over all critisim, hints, tips, suggestions welcome. Bear in mind this is my first ever non trivial Prop program....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1) The disk.start methode returns 0, if all is OK (like all SD card methods). You have it interpreted the other way. I get "Starting Disk: FAIL" if I have a SD card inserted, and "Starting Disk: OK" if I remove it.
2) CP/M sends the codes 13 and 10 for a Newline, PC_Text expects only a 13 in Emulation Mode. You can set PropTerminal in "Normal Terminal Mode", or eliminate the code 10 in the ios output:
condata: 'Console data port
if data <> 10
TV.out(data)
With the second work around it works also with TV_Text, or VGA_Text. The attached picture show, how my startup Screen looks with that modification.
Attached is an update to my 8085 emulator and a screen shot of it booting.
I have made a lot of changes to the emulation code to speed it up somewhat. It seems to do
about 250000 instructions per second. There are still 62 longs free in that cog, which is good as I have not implemented the DAA instruction yet. All memory accesses of the simulated CPU now go through the same function so there is only one place to change if external RAM is desired.
Prior to running CP/M there is now an instruction set test program executed (T8080.COM) this will light a LED pin 23 if all tests pass or pin 22 if there is a failure. This is not a rigorous test, it's just something that grew as I was implementing the instruction handlers. The source code is in T8080.MAC and can be compiled in the SIMH altair simulator on Windows or Linux.
On success T8080 passes control to CP/M and you should see the boot mesage on your propterminal.
Notice I have bumped the RAM available to CP/M to 24K.
This wil start up even without an SD card, but will take a bit longer.
Sadly thats about as far as it goes as typing a command into it results in a BDOS disk select error !!!
Thanks to Ariba and his great propterminal version 4.7 we can now download CP/M disk images to SD cards with cpm2dsk.spin. Note this will trample the first megabyte or so of the SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Propaltair now answers to commands !!! There was a problem with the compare immediate (CPI) emulation resulting in incorrect carry flag setting causing CPM to get its current disk drive wrong. Hence the previos "select" error.
With that fixed commands such as DIR, ERA, TYPE ,LS, SURVEY, PIP etc are working.
Also it now runs C programs compiled with the BDS C compiler. There is a hello world example in the attaced package. Unfortuneatly they do not terminate cleanly and hang CPM.
If anyone wants to play with this, this is what to do:
1. Use a prop demo board or such with an SD card hooked up as per the cookbook example.
Mine is a home made demo board with a 40 pin DIP prop and no EEPROM.
2. Download the file cpm2.dsk to the SD card using cpm2sd.spin in the prop an propterminal version 1.4 or higher.
This expects the file to be in C:\ unless you want to edit cpm2sd.spin.
During download LEDS should count up about 10 times per second. Any slower and your SD card is not cooperating.
This will take 15 minutes or so.
3.Compile and download the emulator altair_sim.spin is the top level.
4. You should see it booting on propterminal.
5. Now try DIR or HELLO as commands.
There is a comprehensive instruction set test called EX8080 included. This however runs very slowly and fails most of the tests !
However as it runs the emulator flashes a heartbeat LED toggling every 100,000 instructions. So we can see we get about 250000 instructions per second.
I will be looking into getting that passing next.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You know, you can make the PropTerminal Window bigger by editing the rows and cols parameters in PropTerminal.ini ?
A question to the SD card file sytem:
When I upload the cpm2.dsk does this overwrite an existing FAT16 file system on the SD card. Or in other words: do I need a fresh SD card only for CPM?
I removed all the loading of CP/M components into RAM from "file" statements in a DAT section and moved the 8080s RAM area into a VAR section. The result of this is that propaltair now uses the real SIMH Altair boot ROM code to load CP/M from the disk image on the SD card.
N.B. The ram_8080 array is filled with zeros by the prop tool. Zero is an 8080 no operation instruction. So the CPU starts at 0000 and executes NOPs until it hits the boot ROM. No reset vector is required. I think this is what the SIMH simulator does.
Anyone trying this will need to load the new cpm2.dsk to SD an card. This image is built for a 24K RAM system such as we have on the prop.
Just now I used the CP/M "format" command to format a drive B: on SD card. I'm so pleased this is all working so easily.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just ran across your cp/m emulation.· This brings back a flood of memories.· I used cp/m alot and still have two functioning systems and a boat load of s/w on 8 inch floppies.· I had just installed 30 mb drives before giving up and going with newer hardware + s/w (windows).· Used the Chicago BBS.· Alot of fun.· I will be interested in your continuing development!
It's nice to here of your interest. For sure I will continue with this when I have time. Next up I wll try to get the 64Mb hard disk emulation working as per the SIMH simulator project. What software do you have on those floppies and do you have any way to get it off of them ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have the S100 cp/m system in storage but I will poke around and see what I can do regarding software. Seems I had PL/I and some other comercial stuff along with alot of s/w sucked up along the journey. I also had some sort of Btrieve database.
With some trepidation, I just threw out all my 8" floppies and the 8" disk drive when I repainted last month. I did have one that converted all the different file formats to be readible on a MSDOS machine. Seems silly that I carried it all the way to Taiwan some 14 years ago. {A boy and his dog or a man and his junk will never be parted.}
I did have a little CP/M machine with Wordstar working. It was cute and a friend who didn't have any money actually used it for her business as an indefinite loaner. Still, I found MSDOS was indeed an bit of an improvement in how it managed the disk space.
Why not consider a FREE Dos machine. www.freedos.org/ That provides the MSDOS 16bit standard in a public domain clone? Is it too much overhead?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Shame about the 8 inch drive. I'd love to get my hands on one.
The thought of an 8086 emulator crossed my mind fleetingly. But the instruction set and addressing modes and memory segmentaion make it a lot bigger project. Which I'm not into taking on. Below is a list of ideas behind propaltair in no particular order:
I was half way through building an real hardware 8085 CPM machine anyway, I have the CPUs, RAM, ROM etc. (This will continue some time)
I discovered the Propeller and decided it would make a graet I/O device for the above. Keyboard, console etc.
So I needed to learn SPIN/PASM and the prop architecture.
Realised I could save a whole lot of hardware wiring by using the prop to emulate an 8085.
The emulator would be a great way to learn SPIN/ASM etc.
The 8085 seemed just doable in one COG but only just. It became a challenge to see if it would fit !
I had been playing with the SIMH 8080 Altair emulator and was taken with the idea of having original Digital Research source code for CP/M
One requirement for propaltair (and my hardware version) is to use SIMH CPM sources, bootloader and hence disk images unchanged. Except for rebuilding for a 24K RAM system.
Nostalgia: The 8085 was used in one of the first major embedded systems projects I worked on circa 1980.
As for 8086 I have some negative feelings anyway. Us young engineers opened up one of the first IBM PC's to arrive in England. I was not so knowledgeable but the older guys around declared it to be brain damaged. These guys used to design their own CPUs for Radar processing so they could say so. I subsequently spent a lot of time programming it and it's followers and began to agree with them. Why couldn't IBM have chosed the Motorola 68000 ? Then there is all that Microsoft nastyness...
More likely I will look into an emulation of the Motorola 6809 running the FLEX operating system. That was a favorite chip to program back in the day. I don't have so much info on FLEX though.
Must stop rambling now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It has become a challenge to get the BDS C compiler to run on the propeller. Thus giving the propeller a self hosting development environment! Problem is it really needs more RAM. Perhaps I'll build a Prop board with some external RAM. Or just wait for Prop II
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
As for licensing, all the CP/M operating system and utilities I'm using have come from the Altair 8800 simulator project http://www.schorn.ch/cpm/intro.html. This all need checking carefully. For example I cannot imagine that Microsoft has ever allowed free distribution of it's assemblers linkers etc. On the other hand I believe our actual CP/M sources and BDS C are allowed out, as it were.
Licensing for CP/M is not a problem. The assets of Digital Research Inc has been acquired several times by several companies. Caldera was the first to open it to the world. It is currently here:
More likely I will look into an emulation of the Motorola 6809 running the FLEX operating system. That was a favorite chip to program back in the day. I don't have so much info on FLEX though.
I have just been running a C version of fibo(29) compiled with the BDS C compiler on propaltair.
Result: Approx. 8 minutes 10 seconds.
Code is implemented recursively as per DeSilva's (I think) suggestion. BDS C does not support 32 bits so its a bit fiddly.
Does anyone have a real CPM machine to compare this against ?
Bill: I know the FLEX users group. I have never used FLEX so this wold be a long time project.
/*
* File: fibo.c
*
* Author: M.Rychlik
*
* Date: 2008-04-28
*
* Decription: Calculation of the 29th member Fibonacci Sequence.
* Written as an exercise of the BDS C compiler output running
* under an 8080 emulator (propaltair) on the Parallax Propeller
* microcontroller. It is performed recursively in the spirit of
* DeSilva's (Parallax Inc, propeller forum) benchmark suggestion.
*
* fibo(29) = 514229
*
* BDS C has no longs (32 bit) so we have to do this a hard way.
*/
#include "stdio.h"
/* Calculate the nth member of the Fibonacci Sequence and place answere in array result */
fibo(n, result)
unsigned n;
unsigned result;
{
unsigned f;
unsigned temp;
if (n > 2)
{
fibo(n-1, result); /* Two recursive calls */
fibo(n-2, f);
temp = result[noparse][[/noparse]0]; /* Keep this for carry detection */
result[noparse][[/noparse]0] += f[noparse][[/noparse]0]; /* Add low 16 bits */
result += f; /* Add high 16 bits */
if (result[noparse][[/noparse]0] < temp) /* Bump high 16 bits if carry from low */
{
result++;
}
return;
}
else
{
result[noparse][[/noparse]0] = 1; /* Just return 1 */
result = 0;
return;
}
}
main()
{
unsigned result;
printf ("fibo(29) = ");
fibo(29, result);
printf ("%04x%04x Hexadecimal\n", result, result[noparse][[/noparse]0]);
}
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
@ heater : You're unreasonably disadvantaging your benchmark against others. Don't worry
about BDS not supporting longs, code fibo() efficiently for 16-bit, use fibo(24) and compare
the result with a fibo(24) run on other platforms. Use fibo(23) if only signed 16-bit available.
The fibo(29) benchmark is not an absolute, so a relative comparison where all platforms can
work as best they can is acceptable and actually more meaningful. Programmers will take it
as read that something which doesn't support 32-bit will usually be more inefficient to that
which does. What's usually wanted is an idea of how well it performs within the constraints
there are.
unsigned fibo( unsigned n )
{
if ( n > 2 )
{
return fibo(n-1) + fibo(n-2);
}
else
{
return 1;
}
}
fibo() and ackermann function are actually really lousy benchmark programs. All they really test is how well you implement the function calling path.I hope we are not propagating their uses as quality of Propeller compiler goodness
p.s. heater,., does your version actually compile and run by the BDS C? I know BSD stands for Brain Dead Software, but if the code actually works, it's even more brain dead than I thought
Forgive me, I now see the light. CP/M provides an 8bit system and in this case it allows the Propeller to do a lot more housekeeping. MS-DOS, FDos, and so are start at 16 bit and go to 32 bit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
···················· Tropically,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
ImageCraft said...
fibo() and ackermann function are actually really lousy benchmark programs. All they really test is how well you implement the function calling path.I hope we are not propagating their uses as quality of Propeller compiler goodness
I think fibo() has become the 'defacto benchmark' simply because we don't have
anything else. You're absolutely right that it only measures limited aspects of the
compiler / target.
It also appears that, like many others, we've fallen for an incorrect implementation
of fibo(), as fibo(0)==0, fibo(1)==1, fibo(2)==1, fibo(3)==2 but that's not what our
version of fibo() gives, we have an 'off by one' error.
PRI fibo( n )
if n < 2
return [b]1[/b]
else
return fibo(n-1) + fibo(n-2)
Should be using ...
PRI fibo( n )
if n < 2
return [b]n[/b]
else
return fibo(n-1) + fibo(n-2)
There's been previous discussion of benchmarking and it would be nice to have a suite
of programs which had more meaningful use, but it seems people here are unwilling to
put in the effort to create those or aren't familiar enough with other benchmarks ( and
often quite complex algorithms ) to be able to convert them to Spin or PASM.
OK I'll run a 16 bit version when I get a moment. Yes fibo() is not much of a bench mark but we have to start somewhere. There must be some other commonly used microcontroller bench marks in C out there. I have not checked yet.
Yes, that fibo was compiled with Leor Zolman's BDS C conpiler from 1979 which he has kindly released the rights to. Source code also. www.bdsoft.com/resources/bdsc.html. This is pre ANSI I guess so not quite the C many will be used to.
As I mentioned before with an external RAM (Or a Prop II) we could host the compiler on the Prop itself. I think the minimum required is about 10K Bytes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
fibo(24) using only 16 bit integers with the BDS C compiler is about 25 seconds.
/* Calculate the nth member of the Fibonacci Sequence (n less than 25) */
unsigned fibo_16(n)
unsigned n;
{
if (n < 2)
{
return (n);
}
else
{
return (fibo_16(n-1) + fibo_16(n-2));
}
}
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
This, the ROM decrypting contest, the Spin interpreter source---man, I need to take a vacation
just to have time to play with the Prop.
Have to dash just now so no time for instructions. Perhaps later today.
If any one wants to cast an eye over it I would be glad to hear any comments suggestions etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Also attached is a screen capture of the CPM boot messages as far as the boot prompt and another image showing what happens when a command is typed. Not much yet but I just had to show someone !
A few notes at random:
1. altair_sim.spin is the top level file which just starts the simulator components and then hangs in a repeat.
2. altair_cpu is the actual 8085 CPU emulator. It's start methods single parameter is a pointer to two longs. First is the address of the 8085's memory second is a pointer to three longs used to communicate with the IO subsystem altair_io for "in" and "out" instructions.
3. altair_mem.spin defines the 8085's memory area (ram_8085) and fills it with 8085 code. Currently this is a jump to the CPM's bios at address zero. Then a jump to CPM's bdos at address 5. Then we pad with zeros untill 100 HEX which is whre CPM loads user programs (Transient Program Area or TPA as it's called). The TPA is loaded with a CPM program from a file p.com. Following the TPA the command processor is loaded from ccp.com, the basic disk operating system is loaded from bdos.com and the bios is loaded from cbiosx.com
These .com files have all been assembled using the altair simulator I linked to earlier running on Windows XP. p.com is actually my instruction set test program which for some reason does not work just now. No matter it's not used but it must be the right length to cause the following files to be loaded at the correct addresses. All these files configured and assembled for a system with 20K of RAM. Seems we could go to 24K.
4. alatair_ios.spin is to take care of the altair console input/output and disk drives and any other things that we may want to drive via "in" and "out" instructions. Currently IO address 0 is used to drive the LEDs on a propeller demo board. Communication with the emulator cog for IN and OUT instructions is done via three longs in ctl_addr. Console IO is directed to PC_tv and PC_keyboard as stated.
An SD card is used for the disks. There is no disk image to boot yet but no worries the Prop has already got all the CPM files in its memory as described. Also means we don't need any have any ROM boot loader code yet. I have done a little testing on the sector read/write but all this is under construction at the moment.
Please someone look this over all critisim, hints, tips, suggestions welcome. Bear in mind this is my first ever non trivial Prop program....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Nice work, so far.
I have 2 impovements:
1) The disk.start methode returns 0, if all is OK (like all SD card methods). You have it interpreted the other way. I get "Starting Disk: FAIL" if I have a SD card inserted, and "Starting Disk: OK" if I remove it.
2) CP/M sends the codes 13 and 10 for a Newline, PC_Text expects only a 13 in Emulation Mode. You can set PropTerminal in "Normal Terminal Mode", or eliminate the code 10 in the ios output:
condata: 'Console data port if data <> 10 TV.out(data)With the second work around it works also with TV_Text, or VGA_Text. The attached picture show, how my startup Screen looks with that modification.
Andy
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have made a lot of changes to the emulation code to speed it up somewhat. It seems to do
about 250000 instructions per second. There are still 62 longs free in that cog, which is good as I have not implemented the DAA instruction yet. All memory accesses of the simulated CPU now go through the same function so there is only one place to change if external RAM is desired.
Prior to running CP/M there is now an instruction set test program executed (T8080.COM) this will light a LED pin 23 if all tests pass or pin 22 if there is a failure. This is not a rigorous test, it's just something that grew as I was implementing the instruction handlers. The source code is in T8080.MAC and can be compiled in the SIMH altair simulator on Windows or Linux.
On success T8080 passes control to CP/M and you should see the boot mesage on your propterminal.
Notice I have bumped the RAM available to CP/M to 24K.
This wil start up even without an SD card, but will take a bit longer.
Sadly thats about as far as it goes as typing a command into it results in a BDOS disk select error !!!
Thanks to Ariba and his great propterminal version 4.7 we can now download CP/M disk images to SD cards with cpm2dsk.spin. Note this will trample the first megabyte or so of the SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Propaltair now answers to commands !!! There was a problem with the compare immediate (CPI) emulation resulting in incorrect carry flag setting causing CPM to get its current disk drive wrong. Hence the previos "select" error.
With that fixed commands such as DIR, ERA, TYPE ,LS, SURVEY, PIP etc are working.
Also it now runs C programs compiled with the BDS C compiler. There is a hello world example in the attaced package. Unfortuneatly they do not terminate cleanly and hang CPM.
If anyone wants to play with this, this is what to do:
1. Use a prop demo board or such with an SD card hooked up as per the cookbook example.
Mine is a home made demo board with a 40 pin DIP prop and no EEPROM.
2. Download the file cpm2.dsk to the SD card using cpm2sd.spin in the prop an propterminal version 1.4 or higher.
This expects the file to be in C:\ unless you want to edit cpm2sd.spin.
During download LEDS should count up about 10 times per second. Any slower and your SD card is not cooperating.
This will take 15 minutes or so.
3.Compile and download the emulator altair_sim.spin is the top level.
4. You should see it booting on propterminal.
5. Now try DIR or HELLO as commands.
There is a comprehensive instruction set test called EX8080 included. This however runs very slowly and fails most of the tests !
However as it runs the emulator flashes a heartbeat LED toggling every 100,000 instructions. So we can see we get about 250000 instructions per second.
I will be looking into getting that passing next.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
very well done!
You know, you can make the PropTerminal Window bigger by editing the rows and cols parameters in PropTerminal.ini ?
A question to the SD card file sytem:
When I upload the cpm2.dsk does this overwrite an existing FAT16 file system on the SD card. Or in other words: do I need a fresh SD card only for CPM?
Andy
I removed all the loading of CP/M components into RAM from "file" statements in a DAT section and moved the 8080s RAM area into a VAR section. The result of this is that propaltair now uses the real SIMH Altair boot ROM code to load CP/M from the disk image on the SD card.
N.B. The ram_8080 array is filled with zeros by the prop tool. Zero is an 8080 no operation instruction. So the CPU starts at 0000 and executes NOPs until it hits the boot ROM. No reset vector is required. I think this is what the SIMH simulator does.
Anyone trying this will need to load the new cpm2.dsk to SD an card. This image is built for a 24K RAM system such as we have on the prop.
Just now I used the CP/M "format" command to format a drive B: on SD card. I'm so pleased this is all working so easily.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Thank you for the well done.
Attached is an 80 column propterminal dump of the CPM survey command. Awesome.
Yes WARNING. cpm2dsk will overwrite anything in the first megabyte of the SD card. Thought I mentioned that already, should have shouted louder.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Regards...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Richard in Michigan
It's nice to here of your interest. For sure I will continue with this when I have time. Next up I wll try to get the 64Mb hard disk emulation working as per the SIMH simulator project. What software do you have on those floppies and do you have any way to get it off of them ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Richard in Michigan
I did have a little CP/M machine with Wordstar working. It was cute and a friend who didn't have any money actually used it for her business as an indefinite loaner. Still, I found MSDOS was indeed an bit of an improvement in how it managed the disk space.
Why not consider a FREE Dos machine. www.freedos.org/ That provides the MSDOS 16bit standard in a public domain clone? Is it too much overhead?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
CP/M runs on an 8080 or 8085 processor. FreeDOS requires an 8086 processor which is a different sort of animal.
Shame about the 8 inch drive. I'd love to get my hands on one.
The thought of an 8086 emulator crossed my mind fleetingly. But the instruction set and addressing modes and memory segmentaion make it a lot bigger project. Which I'm not into taking on. Below is a list of ideas behind propaltair in no particular order:
I was half way through building an real hardware 8085 CPM machine anyway, I have the CPUs, RAM, ROM etc. (This will continue some time)
I discovered the Propeller and decided it would make a graet I/O device for the above. Keyboard, console etc.
So I needed to learn SPIN/PASM and the prop architecture.
Realised I could save a whole lot of hardware wiring by using the prop to emulate an 8085.
The emulator would be a great way to learn SPIN/ASM etc.
The 8085 seemed just doable in one COG but only just. It became a challenge to see if it would fit !
I had been playing with the SIMH 8080 Altair emulator and was taken with the idea of having original Digital Research source code for CP/M
One requirement for propaltair (and my hardware version) is to use SIMH CPM sources, bootloader and hence disk images unchanged. Except for rebuilding for a 24K RAM system.
Nostalgia: The 8085 was used in one of the first major embedded systems projects I worked on circa 1980.
As for 8086 I have some negative feelings anyway. Us young engineers opened up one of the first IBM PC's to arrive in England. I was not so knowledgeable but the older guys around declared it to be brain damaged. These guys used to design their own CPUs for Radar processing so they could say so. I subsequently spent a lot of time programming it and it's followers and began to agree with them. Why couldn't IBM have chosed the Motorola 68000 ? Then there is all that Microsoft nastyness...
More likely I will look into an emulation of the Motorola 6809 running the FLEX operating system. That was a favorite chip to program back in the day. I don't have so much info on FLEX though.
Must stop rambling now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It has become a challenge to get the BDS C compiler to run on the propeller. Thus giving the propeller a self hosting development environment! Problem is it really needs more RAM. Perhaps I'll build a Prop board with some external RAM. Or just wait for Prop II
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Licensing for CP/M is not a problem. The assets of Digital Research Inc has been acquired several times by several companies. Caldera was the first to open it to the world. It is currently here:
http://www.cpm.z80.de/
CP/M software from other companies is in a grey area (abandonware?). Look here:
http://www.retroarchive.org/cpm/
but be prepared to drool...
Bill
Start here:
http://www.flexusergroup.com/flexusergroup/fug1.htm
Bill
Result: Approx. 8 minutes 10 seconds.
Code is implemented recursively as per DeSilva's (I think) suggestion. BDS C does not support 32 bits so its a bit fiddly.
Does anyone have a real CPM machine to compare this against ?
Bill: I know the FLEX users group. I have never used FLEX so this wold be a long time project.
/* * File: fibo.c * * Author: M.Rychlik * * Date: 2008-04-28 * * Decription: Calculation of the 29th member Fibonacci Sequence. * Written as an exercise of the BDS C compiler output running * under an 8080 emulator (propaltair) on the Parallax Propeller * microcontroller. It is performed recursively in the spirit of * DeSilva's (Parallax Inc, propeller forum) benchmark suggestion. * * fibo(29) = 514229 * * BDS C has no longs (32 bit) so we have to do this a hard way. */ #include "stdio.h" /* Calculate the nth member of the Fibonacci Sequence and place answere in array result */ fibo(n, result) unsigned n; unsigned result; { unsigned f; unsigned temp; if (n > 2) { fibo(n-1, result); /* Two recursive calls */ fibo(n-2, f); temp = result[noparse][[/noparse]0]; /* Keep this for carry detection */ result[noparse][[/noparse]0] += f[noparse][[/noparse]0]; /* Add low 16 bits */ result += f; /* Add high 16 bits */ if (result[noparse][[/noparse]0] < temp) /* Bump high 16 bits if carry from low */ { result++; } return; } else { result[noparse][[/noparse]0] = 1; /* Just return 1 */ result = 0; return; } } main() { unsigned result; printf ("fibo(29) = "); fibo(29, result); printf ("%04x%04x Hexadecimal\n", result, result[noparse][[/noparse]0]); }▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
about BDS not supporting longs, code fibo() efficiently for 16-bit, use fibo(24) and compare
the result with a fibo(24) run on other platforms. Use fibo(23) if only signed 16-bit available.
The fibo(29) benchmark is not an absolute, so a relative comparison where all platforms can
work as best they can is acceptable and actually more meaningful. Programmers will take it
as read that something which doesn't support 32-bit will usually be more inefficient to that
which does. What's usually wanted is an idea of how well it performs within the constraints
there are.
unsigned fibo( unsigned n ) { if ( n > 2 ) { return fibo(n-1) + fibo(n-2); } else { return 1; } }p.s. heater,., does your version actually compile and run by the BDS C? I know BSD stands for Brain Dead Software, but if the code actually works, it's even more brain dead than I thought
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PLEASE CONSIDER the following:
Do you want a quickly operational black box solution or the knowledge included therein?······
I think fibo() has become the 'defacto benchmark' simply because we don't have
anything else. You're absolutely right that it only measures limited aspects of the
compiler / target.
It also appears that, like many others, we've fallen for an incorrect implementation
of fibo(), as fibo(0)==0, fibo(1)==1, fibo(2)==1, fibo(3)==2 but that's not what our
version of fibo() gives, we have an 'off by one' error.
blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/133852
Currently used ...
PRI fibo( n ) if n < 2 return [b]1[/b] else return fibo(n-1) + fibo(n-2)Should be using ...
PRI fibo( n ) if n < 2 return [b]n[/b] else return fibo(n-1) + fibo(n-2)There's been previous discussion of benchmarking and it would be nice to have a suite
of programs which had more meaningful use, but it seems people here are unwilling to
put in the effort to create those or aren't familiar enough with other benchmarks ( and
often quite complex algorithms ) to be able to convert them to Spin or PASM.
Optimizing, optimizing....
Yes, that fibo was compiled with Leor Zolman's BDS C conpiler from 1979 which he has kindly released the rights to. Source code also.
www.bdsoft.com/resources/bdsc.html. This is pre ANSI I guess so not quite the C many will be used to.
As I mentioned before with an external RAM (Or a Prop II) we could host the compiler on the Prop itself. I think the minimum required is about 10K Bytes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
/* Calculate the nth member of the Fibonacci Sequence (n less than 25) */ unsigned fibo_16(n) unsigned n; { if (n < 2) { return (n); } else { return (fibo_16(n-1) + fibo_16(n-2)); } }▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.