I only have about 130 longs free in the Altair 8080 emulator CP/M system. This is a shame because I would like to add a few more features:
1. Altair harddisk emulation support (Two times 8MB drives !!)
2. Enhanced SIMH I/O port support so that we can read/write files from a serial connected host.
3. Finish up the break point and single debugging step features.
4. That darned DAA opcode.
Etc etc.
So if anyone has ideas on how to get some space back I'd like to hear.
One thing I'd like to do is put all the PASM code from altair_cpu.spin into the SD card somewhere and load the cog from there thus freeing up 2k of space which is never used when all is up and running. So the sequence would be to load the cpu cog code into the 8080s RAM space, then start the cpu cog pointing it at that binary, then let the space be overwritten by CP/M.
Is there an easy way to get that binary blob out of the Propeller tool or to assemble it separately ?
I will eventually attach a couple 32K RAMS I have to the prop for a full up stand alone CP/M machine but for now it's nice to have something that anyone can try out on a demo board or such.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You can compile the CPU object alone, and save the binary to SD card. The DAT part starts near of the begin of the binary. With only a start and a stop methode the offset is normally $1C. Every additional Spin methode increase the offset by 2 bytes.
For starting the cog, you read the binary from SD card in a free chunk of Hub-Memory and then start it with:
cognew(LoadAddress+$1C, Parpointer)
After that you can reuse the HubMemory. But you have to be carefull with parameters that stay in CogRAM and in HubRAM and use the same name.
I did start looking at a rewritten 8085 emulator. It looks like there is plenty of scope there to be very clever and optimised, but I ran into problems with understanding / handling the flags and never went any further. I'm not very familiar with 8085/Z80 instruction set which doesn't help, so just the basic idea in the attached .spin file (E&OE)
I'm sure someone with 8085 / Z80 experience could produce a very fast, very optimised emulator in PASM. If space gets tight, the frequently used instructions can be kept in Cog, the rest executed as LMM from Hub RAM.
Three other potential tricks; put the 8085 registers in Cog at $000 upwards which allows fast access to them when doing indirect access in PASM, keep the opcode handlers in Cog $000-$0FF so a 256 byte lookup table in Hub can be used to dispatch quickly to the right handler ( jumps from there to $100 and above can be added when needed ), take advantage of the very simple bit-field usage of the instruction set.
For example, the 60+ LD byte instructions can be implemented in just 11 longs. Note that "call #GetByte" increments the return address so it will skip the "call #GetHL"
On the memory size front, I don't expect many will want to add external RAM to their boards, so until a Prop II arrives you could lose some interest in this effort unless it keeps running on what the Prop I has on-chip.
I don't really know CP/M, but is it possible to load a fake device driver ( which never gets called / does nothing ) and have the rest of CP/M adjust around that automatically ? If so, you could fake that load, then in the 8085 CPU emulator map the 8085's address map to hub RAM which is available. As all CP/M execution goes through the 8085 CPU emulator CP/M will think it has 32KB/64KB RAM even though there's a big hole in it and 8085 addresses don't map linearly to hub RAM.
Well, since it's about lunch time, here are some other interesting cookies.
$CAFEBABE ... Java's class cookie
$BABEFACE ... 80's rock tribute
$DEADBEEF ... for the carnivores
$46454542 ... BEEF in ASCII helps spotting code sections "Where's the Beef?"
$1DEADBEE ...
I don't really know CP/M, but is it possible to load a fake device driver ( which never gets called / does nothing ) and have the rest of CP/M adjust around that automatically ? If so, you could fake that load, then in the 8085 CPU emulator map the 8085's address map to hub RAM which is available. As all CP/M execution goes through the 8085 CPU emulator CP/M will think it has 32KB/64KB RAM even though there's a big hole in it and 8085 addresses don't map linearly to hub RAM.
RAM has to be contiguous from 0 on up in CP/M. To accommodate different amounts of memory in a system, CP/M can be relocated by use of a utility to create a new boot image. If you can live with your "hole" at the top of the address space, build a new boot disk. The CP/M memory model for an application program is identical to that of MS-DOS .COM programs since that is where it came from.
Yes those flags are very pesky and not always set consistantly across instructions as you might expect, for example a 16 bit add (DAD) of a pair of 8 bit registers with another pair will set the carry flag but not sign, zero, aux flags as normal 8 bit ops do. Then again a 16 bit increment/decrement (INX/DCX) does not even set the carry flag! Just for fun the 8080/85 does not set parity flag the same way as a Z80 CPU. This is often used by programs to detect what they are running on.
With your inspiration I have been busy trying to speed up the emulator now that it mostly works correctly and I have some regression tests in place.
8080 registers are now at $0000. Somehow executing some of your data at start up seems just wrong but why not? Any way that only saves a few instructions in register look up.
The dispatch table has been in HUB RAM for some time but geting it to use BYTE addresses instead of WORD has stumpped me. Seems to require to many extra jumps in the COG to get from the byte addressable area to the rest of the code.
I have tried to take advantages of the simple bit fields of the op codes and infact have borrowed your MOV reg,reg code wholesale. Hope that's OK with you. In that vein I now have much simplified/faster 8 bit ALU handler and also JMP/CALL/RET handler.
Memory is just limitted and we will live with it until Pop II. As you say it's good if anyone can run this up on a demo board just to see it. I may build an external RAM system for myself though if I feel energetic.
The idea or exporting the less used instructions to LMM leaving space for streamlined frequently used instruction handlers in COG had already occured to me. If only because of that Decimal Adjust for Addition instruction (DAA) that is long winded and complicated and so far I have not found any program that uses it.(It is not implemented in my last release) Now that I have straightend out some code, space issues become more pressing and LMM more appealing.
Now the questions:
Is there an LMM asembler I can use to help with this and/or any directions?
What's the expected speed ratio to PASM ? If it's to slow it may be better to stick with my dense but slow code in COG
For example we discover 16 bit increments are not used vary much what can I do with the following to put ito LMM?
do_inx_b add reg_c, #1
test reg_c, #$100 wz
if_nz add reg_b, #1
and reg_c, #$FF
and reg_b, #$FF
jmp #run
do_inx_d add reg_e, #1
test reg_e, #$100 wz
if_nz add reg_d, #1
and reg_e, #$FF
and reg_d, #$FF
jmp #run
do_inx_h add reg_l, #1
test reg_e, #$100 wz
if_nz add reg_h, #1
and reg_l, #$FF
and reg_h, #$FF
jmp #run
My posts always go on and on.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Most LMM coding I've done has been in the PropTool itself which can mean a not very nice representation of the code which cannot be the usual PASM opcodes, unfortunately no simple #define supported which could macro-ize the LMM opcodes.
Linear LMM is easy and short branching not too bad ( ADD LmmPc,#n*4, SUB LmmPc,#n*4 ) but handling 'djnz', 'tjz', 'tjnz', 'jmp' and 'call' ( other than into the actual Cog itself ) I try to avoid. Put subroutines in the Cog and 'call #Name' works okay, as does 'jmp #Fetch' to exit. 'test' and IF_ condition works well.
Execution speed of LMM to PASM is I believe 8:1, but PhiPi's trick of reversed LMM can get that down to 4:1 AFAIR. Don't worry about that to start with, get traditional (slower) LMM working fully and debugged before making it reversed or you can find it hard to debug, simple #if/#else/#endif would allow both so one could select between a debugging friendly/slow version and a fast/harder to debug version.
Lack of #define and #if are a continuing bane for trying to do LMM within the PropTool itself. I haven't tried Ale's LMM Assembler so cannot comment on that.
I'm about to post a majorly overhauled 8085 emulator in PropAltair. Incorporating much of what I have learned from here recently, cleaner, faster etc etc and most importantly implementing the 8085's DAA (Decimal Adjust for Add) instruction. However befor I do I would like it to pass all tests of the EX8080.COM instruction set test program. Trouble is that depends on a correct implementation of the three unused bits in the 8085 flags register which currently I leave as zero at all times.
Does anyone here happen to know the logic that drives those flags ?
I found a few brief descriptions around the net but am not sure I understand them and I don't want to waste hours experimenting with it.
Ulimately I think I would leave out handling undocumented flags as it will eat cog space and slow us down but I would like to have it pass the test at least once !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm usig sdspiqasm to read/write SD card blocks for the CP/M file system (No FAT layer here). It seems awfully slow. Perhaps an accurate recreationof the old 8" floppy drive experience but is there a faster way to do this on the prop ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
sdspiqasm should be fairly fast. In any event, I would expect it to be faster than an 8" floppy drive since there are no moving parts. I think there's a bit of searching of directories involved in the CP/M file system and that's all being done in 8085 code. Once a file is open, is the I/O better?
Here is an update to the Altair 8080 simulator on Propeller.
This version features:
1. Finally implemented that pesky DAA opcode.
2. Introduced a reverse order LMM virtual machine to handle DAA and a few lesser used opcodes
3. A much slicker ALU implementation
4. A much slicker JMP/CALL/RET implementation
5. Most other ops tweaked.
6. Speed now up to 385 KIPS (48% improvement over v2.0) runs FIBO 24 in 19 seconds.
7. Put the 8080 RAM area back to DAT section and load a test prog and some CP/M files there.
8. As delivered this will run the test prog then CP/M up to the prompt without an SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Funny you should ask, I was just reading the wikipedia entry on the Intel 8080. They say
wikipedia said...
The 8-bit CPU was released in April 1974 running at 2 MHz (at up to 500,000 instructions per second), and is generally considered to be the first truly usable microprocessor CPU design.
There are a few little details I'm quite proud of in this emulator PASM.
1. A dispatch table that can jump you to native PASM or LMM code functions.
2. A way to test a flag and clear it in one instruction using MAX
3. A super quick way to determine the 8080 auxillury flag state using XOR
I'd love to have some "review" comments on this code as I always feel that there must be some PASM tricks and idioms I'm not aware of yet.
Next release will support simulated hard disk drives. A whopping 8MB each !
Seems the current floppy drive simulation is slow because the BIOS I am using does not use DMA so it has to trapes off into Spin for every byte read ! The BIOS cold be modified to use DMA and transfer whole sectors at a time but for now I would like to stick with the BIOS as used by the SIMH Altair Simulator.
Ultimately I want PropAltair to have an Altair front panel with all the LEDs and Switches. see attached image.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I just want an amiga clone. Anybody remember how advanced these were at the time? I'm not exactly talking about emulating an amiga, just duplicating it.
heater,
The SD card driver used in FemtoBasic is designed to work like a DMA. The Spin interface routines don't use the assembly routines this way. They wait for the assembly routines to finish before initiating another operation, but it would be simple to separate the initiation and wait/check parts of the interface routines so the I/O would be done in parallel with the instruction emulation. Download it and read the comments in the SD card (and EEPROM) driver.
@heater, 385KIPS is not bad considering (though I don't know enough about 8080 to be sure) that the up to 500KIPS probably is NOPs).
@justin, I think you are going to have to wait for PropII for that. I would love to see it also, like a single chip Amiga, but we don't have a C64 up and working at this point. There was a guy working on it, but I haven't heard from him in a long time, and he didn't release his code AFAIK
what about trying to actually converting the origional code for the 8085 to a code built for the prop. I don't know how exactly you would do this, but then you would cut down the time taken during emulation.
Pasha,
It's a nice thought, but is a much harder problem than you think, particularly when you consider the thousands of instructions and lines of code involved. A lot of it can be translated mechanically, but a lot has to be looked at, figured out, and hand translated into some kind of equivalent code. This was particularly true years ago when people used a lot of tricks to reduce code size.
Post Edited (Mike Green) : 10/29/2008 2:47:46 PM GMT
Pasha: Nice idea. Converting CPU instructions by itself is no problem but when you take a whole program of them it's kind of hard to figure out which bytes are instructions and which bytes are constants, strings etc. This takes some analysis of the execution path through the bytes in the executable.
Even if you have done that you would still have problems with self modifying code, which of course thinks its modifying 8080 codes not whatever new thing you have translated to. This is also a problem with boot loaders, assemblers, compilers etc.
So while you might be able to build a translator of some kind to get some simple programs translated to your new code its nigh on impossible to get the whole system done to a state where it can boot itself, compile itself, rebuild itself etc.
Would me easier to write a new OS from scratch. Which I think many people are working on for the Prop around here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This sure brings back memories. Like trying to program 1702 Eproms in hex to boot CPM from the floppy drive. What fun.
I built my first computer from a kit consisting of etched boards (5 of them - an 8080 cpu board, a Vector Graphics Preset and Go board, a 16x64 line video display board, a 16K ram board, and a motherboard), schematics, and a parts list. This was an "S100" system which eventually was upgraded with a floppy controller and 2 80K 5.25" drives to run CPM. I even used it to run a small business for several years before upgrading to a PC clone in 82.
I only used CP/M for a few months, on an Intertec SuperBrain www.obsoletecomputermuseum.org/brain/, and only for documentation using WordStar. At the time though I was involved in designing process monitoring/control systems using multiple 8085s. No operating system, just bare assembler. We were up to our eyeballs in 2716 EPROMS.
I still have an 8085 chip from that era, one day I'll build up to a CP/M system. That's what inspired this whole Prop emulation, I was to lazy to start on the real hardware version[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A group at http://groups.google.com.au/group/n8vem?hl=en is working on hybridising CP/M and the Propeller. At the moment, the design is a standalone CP/M board running a Z80, with the propeller running the vga display, keyboard etc.
But given the inspiration here, there is much that could be ported over to the Propeller. Possibly even the whole thing!
Just a note re 8080 and Z80 and some of the posts earlier in this thread, CP/M was written in 8080 mnemonics. There is a CP/M program to convert back and forth to Z80, and because I understand Z80 better, I've been writing modifications to CP/M in Z80 code. But what I've found is that one hardly ever actually uses Z80 codes. Maybe LDIR a couple of times but there is an 8080 equivalent for that using a few opcodes. So 8080 is fine for running CP/M, even if it is written in Z80 mnemonics but only uses opcodes that are both 8080 and Z80. There would thus be no great need to try to code all those extra Z80 opcodes onto the propeller.
One thing that is great about CP/M is the ability to use the vast existing library of programs. So, in modifying the CP/M source code, it was a matter of getting this off the SIMH site, saving as a simple text file, firing up a CP/M board, sending over the text file using xmodem, editing a bit in Wordstar, converting it to Z80 opcodes using xzi.com, recompiling it to machine code using M80, and sending copies of all the files back to a PC and thence onto the internet just for safekeeping. A board that can recompile its own operating system is very useful.
CP/M boards are pretty quick to solder up and with all the parts to hand it is possible to build one in about 35 minutes. The N8VEM uses a single 512k ram chip that is battery backed that has 64k for CP/M space and the rest is disk drive A. So loads etc are amazingly fast and a boot to a A> prompt is well under a second.
I see the possibility of more things being done on the propeller...
Sorry I missed your comment. N8VEM looks interesting, I had not heard of it before, I'll have to delve into what they are up to.
As I've said before, my first plan was along those lines. Hook up an 8085 CP/M board using a Propeller as the screen, keyboard, disk etc controllers. But then I got to lazy to build the hardware and just coded the emulator. Turns out of course that building the hardware with a real 8085 would have been quicker.
Interesting what you say about CP/M being coded in 8080 mnemonics because the only sources I have seen are in Z80 mnemonics, the ones from the SIMH project. I always thought this was a bit odd as Digital Research would surely not ship code out that depended on Microsoft's M80 assembler ! Now you perhaps give me the answer, xzi.com.
In fact what bugs me about the CP/M from the SIMH project is that the process to rebuild CP/M from within CP/M relies on Microsoft's tools. What I'd like to find is a sure fire recipe for doing that using only Digital Research 's assembler etc.
I think my next step will be a twin propeller CP/M solution with an external RAM. One Prop for CP/M and one for the terminal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Please join the N8VEM group. 68 members at last count. It is evolving rapidly. (a bit like the Propeller!)
Current projects:
A hard drive interface
A floppy disk drive interface
An SD card interface
The propeller interface for vga screen and keyboard
Wireless mesh interface to multiple boards - ability to transfer files etc
Real world interface - relays etc
Already working:
Keyboard, 20x4 LCD screen, rapid downloads via RS232, all CP/M software, interface to the internet via a PC etc.
There are two versions of the board - the main board and a mini version.
This is where things were up to a few months ago - it has got even simpler since then
All software is free. Hardware (board) is a nominal cost from the US or Australia. Parts are very reasonably priced from places like Jameco, Futurlec or Digikey. 15 ICs ranging from $6 for the ram chip to 20c for digital logic chips. The model is that this is a "not for profit" project being run by a group of hobbyists in the old school way where people from all over the world get together and build something as a group.
It is certainly possible to run basic on the board, or C or machine code, plus wordstar and other text editors. Indeed, anything that runs on CP/M. Instant boot to a A> prompt with no moving parts is a big plus. There are huge CP/M libraries on the 'net.
What isn't working very well is the website - it is not as "welcoming" as it could be, ie there is no picture on the front page of the board. The pictures are hidden in the files section and these don't come up in chronological order as the default. The discussion happens to be just the latest topics which may not necessarily be a step by step guide to getting a board working. Just join and say "hi".
What the N8VEM group is very keen to do is to work with the Propeller forum to build a hybrid model. Some things are better done on the propeller eg display and keyboard. Some are better done within CP/M eg if you want software for a text editor, it makes more sense to use an existing CP/M one that to write one from scratch. Ditto a BASIC compiler or interpreter. There is a feeling amongst some in the group that a number of things on the board could be run instead by a propeller.
What is it for? Well, retrocomputing is one use. Playing games. For myself, I want to be able to control sprinklers and lights and sense moisture and detect a gate and other things around the house, and a CP/M board is the minimum system that is capable of being reprogrammed via wireless and has the necessary smarts to run a wireless mesh, and not use any secret or proprietory code.
What the N8VEM doesn't have is a lot of Propeller expertise. Eg someone (anyone) who would know how to code VT100 escape sequences into a terminal so that the cursor can move around and run Wordstar and other text editors that needed cursor movement.
Post Edited (Dr_Acula (James Moxham)) : 12/22/2008 2:05:21 PM GMT
I'll probably sign up for the N8VEM when I have a free moment or ten may even get a board.
However I think I have a different take on all this. I will one day build my original plan of using am 8080 together with some RAM with one or more Propellers as the ONLY peripheral devices responding as IO ports. Thus no need for old original style parallel or serial port chips etc.
Alternatively a multi Prop board and use the emulator as I said before.
I have no interest it getting real floppy or hard drives connected, better to just use and SD card or FLASH chips.
On of my guiding principles is to be able to use the CP/M sources from the SIMH project unchanged, so as not to have to maintain a separate CP/M version. So it is necessary for the Prop to implement SIMH's idea of floppy/hard disk and serial ports etc.
The VT100 terminal emulation on a Prop is a major part of this, sadly I have no solution for it yet. I suspect someone here as done this already though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Parallel chips - agree. Some I/O is handy eg to turn on a light/motor but the propeller can do that.
Serial chips - ditto. The propeller can do that too. A max3232 makes the serial 'robost'.
Real floppy - personally I agree too. The 448k of A> battery backed ram disk is more than enough for most applications, though it gets a bit tight if you want wordstar and mbasic on the same board at the same time. You have to leave out the wordstar help files and wordstar gives a message about that when it boots (but it still runs ok).
Real IDE - the N8VEM IDE is *almost* ready - I think it could be very handy to have mass storage, especially on old (freebie) hard drives.
SD card/flash - the key is actually writing the drivers so they behave as a drive ie you can type DIR and it lists all the files.
CP/M sources from the SIMH - the N8VEM can do that and it is extremely handy. Just collect up any/all .COM files etc off each SIMH disk image, use W.COM to copy to a PC directory, then use xmodem within hyperterminal to transfer which files you need on the board. On the N8VEM you run XMODEM R MYFILE.COM and it sits there waiting till hyperterminal sends it over. Battery backed ram means you only have to do this once. SD storage would be even better!
I'm looking at the source code for the N8VEM CP/M in terms of what it needs to run a minimum SIMH simulation. It doesn't need a floppy drive. It only needs one static drive eg drive A> and you can put everything on that common drive. (you can emulate drive B>, C> etc if you want but that is only for the purposes of organising files into groups like in directories). Serial ports - well that is handled in CP/M but once a uart is set up with baud rates etc, it is only one machine code instruction to send a byte out, and to read a byte, one instruction to check if a byte is there and one instruction to read it.
In terms of porting the N8VEM onto propeller, most of the CP/M source code would stay exactly as is. And if you have all the 8080 instructions then it should work. Maybe you might need to code LDIR - I think that is the only Z80 instruction but there is a workaround in that in lots of books on 8080/Z80 code.
If you can address a 512k ram chip directly off a propeller then much of the N8VEM would port over directly. So you would need 19 address lines and 8 data lines and /wr and /cs. That uses quite a few propeller pins. Battery back the ram with a DS1210. The N8VEM boots up with a hardware switch that puts maps the lower 32k of the 64k CPU memory as eprom. Maybe you don't need the ram chip. Emulate 64k of CPU space on a propeller (if that is possible) - or use external 64k of ram chips, and run the mass storage of an SD card. The key is the software - and while it sounds simple to describe, Andew Lynch has spent two years turning a 512k ram chip into an A> drive. The smarts are all in the modified version of CP/M.
I'm trying to upload the schematic of the minimum system to emulate but it tells me .PDFs are not allowed. I'll find another way but looking at the schematic, it is essentially a Z80, 32k eprom, 512k ram chip, battery backup for the ram chip, some glue logic to select rom/ram, a regulator, uart, clock for the uart, clock for the z80, and a max232. (go to the N8VEM site http://groups.google.com/group/n8vem, files, sort by uploaded date and the schematic is mini_n8vem_schematic.pdf)
Much of that can be done on a propeller. The uart, glue logic, clocks etc. The max232 might still be handy as a serial port but not necessary. That just leaves the z80 (or 8080), eprom and ram chip. If you can emulate the z80 in code like you have and can do the full 64k of ram then that will work. The eprom and the 448k of the ram chip used as drive A> - well that could exist on a SD card. CP/M works in 128 byte chunks, so just hook into the relevant bits of CP/M and read them off a SD card instead.
Re speed, one thing I've found is that speed is not so important. I've been running 3.6Mhz to 8Mhz chips and it doesn't make a great deal of difference. The most important thing is the uart speed back to the terminal (which is also the download speed for files). 9600baud is tedious. 38k is fantastic. But running on a propeller, displaying a character to the monitor would run even faster than 38k because it isn't going up a serial line - it is all internal in the chip and going straight out onto a vga screen. The absolute slowest thing on CP/M that I have found is compiling a basic program. You don't do that very often as mostly a program is written and debugged in the MBASIC interpreter, but when you finally go to compile it takes a minute. It is possibly faster to port to the SIMH and compile and port back - the SIMH is emulating a 200Mhz Z80 on my 2.4Ghz computer. Otherwise, most of the time CP/M spends its time in a loop waiting for keyboard input.
Post Edited (Dr_Acula (James Moxham)) : 12/22/2008 10:12:50 PM GMT
Comments
1. Altair harddisk emulation support (Two times 8MB drives !!)
2. Enhanced SIMH I/O port support so that we can read/write files from a serial connected host.
3. Finish up the break point and single debugging step features.
4. That darned DAA opcode.
Etc etc.
So if anyone has ideas on how to get some space back I'd like to hear.
One thing I'd like to do is put all the PASM code from altair_cpu.spin into the SD card somewhere and load the cog from there thus freeing up 2k of space which is never used when all is up and running. So the sequence would be to load the cpu cog code into the 8080s RAM space, then start the cpu cog pointing it at that binary, then let the space be overwritten by CP/M.
Is there an easy way to get that binary blob out of the Propeller tool or to assemble it separately ?
I will eventually attach a couple 32K RAMS I have to the prop for a full up stand alone CP/M machine but for now it's nice to have something that anyone can try out on a demo board or such.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
For starting the cog, you read the binary from SD card in a free chunk of Hub-Memory and then start it with:
cognew(LoadAddress+$1C, Parpointer)
After that you can reuse the HubMemory. But you have to be carefull with parameters that stay in CogRAM and in HubRAM and use the same name.
Andy
LONG $FEEDFACE
ORG
' Code begins here
And then search for $FEEDFACE in the loaded binary?
I'm sure someone with 8085 / Z80 experience could produce a very fast, very optimised emulator in PASM. If space gets tight, the frequently used instructions can be kept in Cog, the rest executed as LMM from Hub RAM.
Three other potential tricks; put the 8085 registers in Cog at $000 upwards which allows fast access to them when doing indirect access in PASM, keep the opcode handlers in Cog $000-$0FF so a 256 byte lookup table in Hub can be used to dispatch quickly to the right handler ( jumps from there to $100 and above can be added when needed ), take advantage of the very simple bit-field usage of the instruction set.
For example, the 60+ LD byte instructions can be implemented in just 11 longs. Note that "call #GetByte" increments the return address so it will skip the "call #GetHL"
opc3E ; LD A,#nn 3E nn opc06 ; LD B,#nn 06 nn opc0E ; LD C,#nn 0E nn opc16 ; LD D,#nn 16 nn opc1E ; LD E,#nn 1E nn opc26 ; LD H,#nn 26 nn opc2E ; LD L,#nn 2E nn call #GetByte opc7E ; LD A,(HL) 7E opc46 ; LD B,(HL) 46 opc4E ; LD C,(HL) 4E opc56 ; LD D,(HL) 56 opc5E ; LD E,(HL) 5E opc66 ; LD H,(HL) 66 opc6E ; LD L,(HL) 6E call #GetHL opc7F ; LD A,A 7F opc78 ; LD A,B 78 opc79 ; LD A,C 79 opc7A ; LD A,D 7A opc7B ; LD A,E 7B opc7C ; LD A,H 7C opc7D ; LD A,L 7D opc47 ; LD B,A 47 opc40 ; LD B,B 40 opc41 ; LD B,C 41 opc42 ; LD B,D 42 opc43 ; LD B,E 43 opc44 ; LD B,H 44 opc45 ; LD B,L 45 opc4F ; LD C,A 4F opc48 ; LD C,B 48 opc49 ; LD C,C 49 opc4A ; LD C,D 4A opc4B ; LD C,E 4B opc4C ; LD C,H 4C opc4D ; LD C,L 4D opc57 ; LD D,A 57 opc50 ; LD D,B 50 opc51 ; LD D,C 51 opc52 ; LD D,D 52 opc53 ; LD D,E 53 opc54 ; LD D,H 54 opc55 ; LD D,L 55 opc5F ; LD E,A 5F opc58 ; LD E,B 58 opc59 ; LD E,C 59 opc5A ; LD E,D 5A opc5B ; LD E,E 5B opc5C ; LD E,H 5C opc5D ; LD E,L 5D opc67 ; LD H,A 67 opc60 ; LD H,B 60 opc61 ; LD H,C 61 opc62 ; LD H,D 62 opc63 ; LD H,E 63 opc64 ; LD H,H 64 opc65 ; LD H,L 65 opc6F ; LD L,A 6F opc68 ; LD L,B 68 opc69 ; LD L,C 69 opc6A ; LD L,D 6A opc6B ; LD L,E 6B opc6C ; LD L,H 6C opc6D ; LD L,L 6D ror opc,#3 and opc,k_FFFF_FFE07 movd opcLD_DstSrc,opc rol opc,#3 and opc,#7 movs opcLD_DstSrc,opc add pc,#1 opcLD_DstSrc mov 0-0,0-0 jmp #FetchOn the memory size front, I don't expect many will want to add external RAM to their boards, so until a Prop II arrives you could lose some interest in this effort unless it keeps running on what the Prop I has on-chip.
I don't really know CP/M, but is it possible to load a fake device driver ( which never gets called / does nothing ) and have the rest of CP/M adjust around that automatically ? If so, you could fake that load, then in the 8085 CPU emulator map the 8085's address map to hub RAM which is available. As all CP/M execution goes through the 8085 CPU emulator CP/M will think it has 32KB/64KB RAM even though there's a big hole in it and 8085 addresses don't map linearly to hub RAM.
$FEEDFACE
Well, since it's about lunch time, here are some other interesting cookies.
$CAFEBABE ... Java's class cookie
$BABEFACE ... 80's rock tribute
$DEADBEEF ... for the carnivores
$46454542 ... BEEF in ASCII helps spotting code sections "Where's the Beef?"
$1DEADBEE ...
So, is the CPM emulator written in .spin or asm ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
BEEFFACE sounds cool also
RAM has to be contiguous from 0 on up in CP/M. To accommodate different amounts of memory in a system, CP/M can be relocated by use of a utility to create a new boot image. If you can live with your "hole" at the top of the address space, build a new boot disk. The CP/M memory model for an application program is identical to that of MS-DOS .COM programs since that is where it came from.
Bill
Yes those flags are very pesky and not always set consistantly across instructions as you might expect, for example a 16 bit add (DAD) of a pair of 8 bit registers with another pair will set the carry flag but not sign, zero, aux flags as normal 8 bit ops do. Then again a 16 bit increment/decrement (INX/DCX) does not even set the carry flag! Just for fun the 8080/85 does not set parity flag the same way as a Z80 CPU. This is often used by programs to detect what they are running on.
With your inspiration I have been busy trying to speed up the emulator now that it mostly works correctly and I have some regression tests in place.
8080 registers are now at $0000. Somehow executing some of your data at start up seems just wrong but why not? Any way that only saves a few instructions in register look up.
The dispatch table has been in HUB RAM for some time but geting it to use BYTE addresses instead of WORD has stumpped me. Seems to require to many extra jumps in the COG to get from the byte addressable area to the rest of the code.
I have tried to take advantages of the simple bit fields of the op codes and infact have borrowed your MOV reg,reg code wholesale. Hope that's OK with you. In that vein I now have much simplified/faster 8 bit ALU handler and also JMP/CALL/RET handler.
Memory is just limitted and we will live with it until Pop II. As you say it's good if anyone can run this up on a demo board just to see it. I may build an external RAM system for myself though if I feel energetic.
The idea or exporting the less used instructions to LMM leaving space for streamlined frequently used instruction handlers in COG had already occured to me. If only because of that Decimal Adjust for Addition instruction (DAA) that is long winded and complicated and so far I have not found any program that uses it.(It is not implemented in my last release) Now that I have straightend out some code, space issues become more pressing and LMM more appealing.
Now the questions:
Is there an LMM asembler I can use to help with this and/or any directions?
What's the expected speed ratio to PASM ? If it's to slow it may be better to stick with my dense but slow code in COG
For example we discover 16 bit increments are not used vary much what can I do with the following to put ito LMM?
do_inx_b add reg_c, #1 test reg_c, #$100 wz if_nz add reg_b, #1 and reg_c, #$FF and reg_b, #$FF jmp #run do_inx_d add reg_e, #1 test reg_e, #$100 wz if_nz add reg_d, #1 and reg_e, #$FF and reg_d, #$FF jmp #run do_inx_h add reg_l, #1 test reg_e, #$100 wz if_nz add reg_h, #1 and reg_l, #$FF and reg_h, #$FF jmp #runMy posts always go on and on.....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
http://forums.parallax.com/forums/?f=25&m=233324&g=233324#m233324
It needs a bit more work, but it compiles
Ale
Linear LMM is easy and short branching not too bad ( ADD LmmPc,#n*4, SUB LmmPc,#n*4 ) but handling 'djnz', 'tjz', 'tjnz', 'jmp' and 'call' ( other than into the actual Cog itself ) I try to avoid. Put subroutines in the Cog and 'call #Name' works okay, as does 'jmp #Fetch' to exit. 'test' and IF_ condition works well.
Execution speed of LMM to PASM is I believe 8:1, but PhiPi's trick of reversed LMM can get that down to 4:1 AFAIR. Don't worry about that to start with, get traditional (slower) LMM working fully and debugged before making it reversed or you can find it hard to debug, simple #if/#else/#endif would allow both so one could select between a debugging friendly/slow version and a fast/harder to debug version.
Lack of #define and #if are a continuing bane for trying to do LMM within the PropTool itself. I haven't tried Ale's LMM Assembler so cannot comment on that.
Does anyone here happen to know the logic that drives those flags ?
I found a few brief descriptions around the net but am not sure I understand them and I don't want to waste hours experimenting with it.
Ulimately I think I would leave out handling undocumented flags as it will eat cog space and slow us down but I would like to have it pass the test at least once !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It is.
Undocumented 8085 Instructions and Flags
Attachment :
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This version features:
1. Finally implemented that pesky DAA opcode.
2. Introduced a reverse order LMM virtual machine to handle DAA and a few lesser used opcodes
3. A much slicker ALU implementation
4. A much slicker JMP/CALL/RET implementation
5. Most other ops tweaked.
6. Speed now up to 385 KIPS (48% improvement over v2.0) runs FIBO 24 in 19 seconds.
7. Put the 8080 RAM area back to DAT section and load a test prog and some CP/M files there.
8. As delivered this will run the test prog then CP/M up to the prompt without an SD card.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
en.wikipedia.org/wiki/Intel_8080
There are a few little details I'm quite proud of in this emulator PASM.
1. A dispatch table that can jump you to native PASM or LMM code functions.
2. A way to test a flag and clear it in one instruction using MAX
3. A super quick way to determine the 8080 auxillury flag state using XOR
I'd love to have some "review" comments on this code as I always feel that there must be some PASM tricks and idioms I'm not aware of yet.
Next release will support simulated hard disk drives. A whopping 8MB each !
Seems the current floppy drive simulation is slow because the BIOS I am using does not use DMA so it has to trapes off into Spin for every byte read ! The BIOS cold be modified to use DMA and transfer whole sectors at a time but for now I would like to stick with the BIOS as used by the SIMH Altair Simulator.
Ultimately I want PropAltair to have an Altair front panel with all the LEDs and Switches. see attached image.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The SD card driver used in FemtoBasic is designed to work like a DMA. The Spin interface routines don't use the assembly routines this way. They wait for the assembly routines to finish before initiating another operation, but it would be simple to separate the initiation and wait/check parts of the interface routines so the I/O would be done in parallel with the instruction emulation. Download it and read the comments in the SD card (and EEPROM) driver.
@justin, I think you are going to have to wait for PropII for that. I would love to see it also, like a single chip Amiga, but we don't have a C64 up and working at this point. There was a guy working on it, but I haven't heard from him in a long time, and he didn't release his code AFAIK
It's a nice thought, but is a much harder problem than you think, particularly when you consider the thousands of instructions and lines of code involved. A lot of it can be translated mechanically, but a lot has to be looked at, figured out, and hand translated into some kind of equivalent code. This was particularly true years ago when people used a lot of tricks to reduce code size.
Post Edited (Mike Green) : 10/29/2008 2:47:46 PM GMT
Even if you have done that you would still have problems with self modifying code, which of course thinks its modifying 8080 codes not whatever new thing you have translated to. This is also a problem with boot loaders, assemblers, compilers etc.
So while you might be able to build a translator of some kind to get some simple programs translated to your new code its nigh on impossible to get the whole system done to a state where it can boot itself, compile itself, rebuild itself etc.
Would me easier to write a new OS from scratch. Which I think many people are working on for the Prop around here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I built my first computer from a kit consisting of etched boards (5 of them - an 8080 cpu board, a Vector Graphics Preset and Go board, a 16x64 line video display board, a 16K ram board, and a motherboard), schematics, and a parts list. This was an "S100" system which eventually was upgraded with a floppy controller and 2 80K 5.25" drives to run CPM. I even used it to run a small business for several years before upgrading to a PC clone in 82.
I still have an 8085 chip from that era, one day I'll build up to a CP/M system. That's what inspired this whole Prop emulation, I was to lazy to start on the real hardware version[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
A group at http://groups.google.com.au/group/n8vem?hl=en is working on hybridising CP/M and the Propeller. At the moment, the design is a standalone CP/M board running a Z80, with the propeller running the vga display, keyboard etc.
But given the inspiration here, there is much that could be ported over to the Propeller. Possibly even the whole thing!
Just a note re 8080 and Z80 and some of the posts earlier in this thread, CP/M was written in 8080 mnemonics. There is a CP/M program to convert back and forth to Z80, and because I understand Z80 better, I've been writing modifications to CP/M in Z80 code. But what I've found is that one hardly ever actually uses Z80 codes. Maybe LDIR a couple of times but there is an 8080 equivalent for that using a few opcodes. So 8080 is fine for running CP/M, even if it is written in Z80 mnemonics but only uses opcodes that are both 8080 and Z80. There would thus be no great need to try to code all those extra Z80 opcodes onto the propeller.
One thing that is great about CP/M is the ability to use the vast existing library of programs. So, in modifying the CP/M source code, it was a matter of getting this off the SIMH site, saving as a simple text file, firing up a CP/M board, sending over the text file using xmodem, editing a bit in Wordstar, converting it to Z80 opcodes using xzi.com, recompiling it to machine code using M80, and sending copies of all the files back to a PC and thence onto the internet just for safekeeping. A board that can recompile its own operating system is very useful.
CP/M boards are pretty quick to solder up and with all the parts to hand it is possible to build one in about 35 minutes. The N8VEM uses a single 512k ram chip that is battery backed that has 64k for CP/M space and the rest is disk drive A. So loads etc are amazingly fast and a boot to a A> prompt is well under a second.
I see the possibility of more things being done on the propeller...
Sorry I missed your comment. N8VEM looks interesting, I had not heard of it before, I'll have to delve into what they are up to.
As I've said before, my first plan was along those lines. Hook up an 8085 CP/M board using a Propeller as the screen, keyboard, disk etc controllers. But then I got to lazy to build the hardware and just coded the emulator. Turns out of course that building the hardware with a real 8085 would have been quicker.
Interesting what you say about CP/M being coded in 8080 mnemonics because the only sources I have seen are in Z80 mnemonics, the ones from the SIMH project. I always thought this was a bit odd as Digital Research would surely not ship code out that depended on Microsoft's M80 assembler ! Now you perhaps give me the answer, xzi.com.
In fact what bugs me about the CP/M from the SIMH project is that the process to rebuild CP/M from within CP/M relies on Microsoft's tools. What I'd like to find is a sure fire recipe for doing that using only Digital Research 's assembler etc.
I think my next step will be a twin propeller CP/M solution with an external RAM. One Prop for CP/M and one for the terminal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Current projects:
A hard drive interface
A floppy disk drive interface
An SD card interface
The propeller interface for vga screen and keyboard
Wireless mesh interface to multiple boards - ability to transfer files etc
Real world interface - relays etc
Already working:
Keyboard, 20x4 LCD screen, rapid downloads via RS232, all CP/M software, interface to the internet via a PC etc.
There are two versions of the board - the main board and a mini version.
This is where things were up to a few months ago - it has got even simpler since then
http://www.instructables.com/id/Robot_Brain_Build_a_single_board_computer_in_an_e/
All software is free. Hardware (board) is a nominal cost from the US or Australia. Parts are very reasonably priced from places like Jameco, Futurlec or Digikey. 15 ICs ranging from $6 for the ram chip to 20c for digital logic chips. The model is that this is a "not for profit" project being run by a group of hobbyists in the old school way where people from all over the world get together and build something as a group.
It is certainly possible to run basic on the board, or C or machine code, plus wordstar and other text editors. Indeed, anything that runs on CP/M. Instant boot to a A> prompt with no moving parts is a big plus. There are huge CP/M libraries on the 'net.
What isn't working very well is the website - it is not as "welcoming" as it could be, ie there is no picture on the front page of the board. The pictures are hidden in the files section and these don't come up in chronological order as the default. The discussion happens to be just the latest topics which may not necessarily be a step by step guide to getting a board working. Just join and say "hi".
What the N8VEM group is very keen to do is to work with the Propeller forum to build a hybrid model. Some things are better done on the propeller eg display and keyboard. Some are better done within CP/M eg if you want software for a text editor, it makes more sense to use an existing CP/M one that to write one from scratch. Ditto a BASIC compiler or interpreter. There is a feeling amongst some in the group that a number of things on the board could be run instead by a propeller.
What is it for? Well, retrocomputing is one use. Playing games. For myself, I want to be able to control sprinklers and lights and sense moisture and detect a gate and other things around the house, and a CP/M board is the minimum system that is capable of being reprogrammed via wireless and has the necessary smarts to run a wireless mesh, and not use any secret or proprietory code.
What the N8VEM doesn't have is a lot of Propeller expertise. Eg someone (anyone) who would know how to code VT100 escape sequences into a terminal so that the cursor can move around and run Wordstar and other text editors that needed cursor movement.
Post Edited (Dr_Acula (James Moxham)) : 12/22/2008 2:05:21 PM GMT
However I think I have a different take on all this. I will one day build my original plan of using am 8080 together with some RAM with one or more Propellers as the ONLY peripheral devices responding as IO ports. Thus no need for old original style parallel or serial port chips etc.
Alternatively a multi Prop board and use the emulator as I said before.
I have no interest it getting real floppy or hard drives connected, better to just use and SD card or FLASH chips.
On of my guiding principles is to be able to use the CP/M sources from the SIMH project unchanged, so as not to have to maintain a separate CP/M version. So it is necessary for the Prop to implement SIMH's idea of floppy/hard disk and serial ports etc.
The VT100 terminal emulation on a Prop is a major part of this, sadly I have no solution for it yet. I suspect someone here as done this already though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Serial chips - ditto. The propeller can do that too. A max3232 makes the serial 'robost'.
Real floppy - personally I agree too. The 448k of A> battery backed ram disk is more than enough for most applications, though it gets a bit tight if you want wordstar and mbasic on the same board at the same time. You have to leave out the wordstar help files and wordstar gives a message about that when it boots (but it still runs ok).
Real IDE - the N8VEM IDE is *almost* ready - I think it could be very handy to have mass storage, especially on old (freebie) hard drives.
SD card/flash - the key is actually writing the drivers so they behave as a drive ie you can type DIR and it lists all the files.
CP/M sources from the SIMH - the N8VEM can do that and it is extremely handy. Just collect up any/all .COM files etc off each SIMH disk image, use W.COM to copy to a PC directory, then use xmodem within hyperterminal to transfer which files you need on the board. On the N8VEM you run XMODEM R MYFILE.COM and it sits there waiting till hyperterminal sends it over. Battery backed ram means you only have to do this once. SD storage would be even better!
I'm looking at the source code for the N8VEM CP/M in terms of what it needs to run a minimum SIMH simulation. It doesn't need a floppy drive. It only needs one static drive eg drive A> and you can put everything on that common drive. (you can emulate drive B>, C> etc if you want but that is only for the purposes of organising files into groups like in directories). Serial ports - well that is handled in CP/M but once a uart is set up with baud rates etc, it is only one machine code instruction to send a byte out, and to read a byte, one instruction to check if a byte is there and one instruction to read it.
In terms of porting the N8VEM onto propeller, most of the CP/M source code would stay exactly as is. And if you have all the 8080 instructions then it should work. Maybe you might need to code LDIR - I think that is the only Z80 instruction but there is a workaround in that in lots of books on 8080/Z80 code.
If you can address a 512k ram chip directly off a propeller then much of the N8VEM would port over directly. So you would need 19 address lines and 8 data lines and /wr and /cs. That uses quite a few propeller pins. Battery back the ram with a DS1210. The N8VEM boots up with a hardware switch that puts maps the lower 32k of the 64k CPU memory as eprom. Maybe you don't need the ram chip. Emulate 64k of CPU space on a propeller (if that is possible) - or use external 64k of ram chips, and run the mass storage of an SD card. The key is the software - and while it sounds simple to describe, Andew Lynch has spent two years turning a 512k ram chip into an A> drive. The smarts are all in the modified version of CP/M.
I'm trying to upload the schematic of the minimum system to emulate but it tells me .PDFs are not allowed. I'll find another way but looking at the schematic, it is essentially a Z80, 32k eprom, 512k ram chip, battery backup for the ram chip, some glue logic to select rom/ram, a regulator, uart, clock for the uart, clock for the z80, and a max232. (go to the N8VEM site http://groups.google.com/group/n8vem, files, sort by uploaded date and the schematic is mini_n8vem_schematic.pdf)
Much of that can be done on a propeller. The uart, glue logic, clocks etc. The max232 might still be handy as a serial port but not necessary. That just leaves the z80 (or 8080), eprom and ram chip. If you can emulate the z80 in code like you have and can do the full 64k of ram then that will work. The eprom and the 448k of the ram chip used as drive A> - well that could exist on a SD card. CP/M works in 128 byte chunks, so just hook into the relevant bits of CP/M and read them off a SD card instead.
Re speed, one thing I've found is that speed is not so important. I've been running 3.6Mhz to 8Mhz chips and it doesn't make a great deal of difference. The most important thing is the uart speed back to the terminal (which is also the download speed for files). 9600baud is tedious. 38k is fantastic. But running on a propeller, displaying a character to the monitor would run even faster than 38k because it isn't going up a serial line - it is all internal in the chip and going straight out onto a vga screen. The absolute slowest thing on CP/M that I have found is compiling a basic program. You don't do that very often as mostly a program is written and debugged in the MBASIC interpreter, but when you finally go to compile it takes a minute. It is possibly faster to port to the SIMH and compile and port back - the SIMH is emulating a 200Mhz Z80 on my 2.4Ghz computer. Otherwise, most of the time CP/M spends its time in a loop waiting for keyboard input.
Post Edited (Dr_Acula (James Moxham)) : 12/22/2008 10:12:50 PM GMT