Heater: Since you know by tracing what is in all the registers and flags, maybe you could write a small piece of code that sets the 8080 to this point, and follow it with a few instructions that display the results. Then you could ask on one of the forums using real 8080's if someone would be kind enough to run your piece of code and report back.
Nice suggestions guys but not so simple. PropAltair has single step capability, already used a lot but currently commented out due to lack of COG space. To use it I have to remove some opcodes from emulation. Doable but tedious.
Here is what I found so far:
1. The DAA instruction is dependent on the setting of the Auxiliary Carry flag (half carry) by previous instructions. Namely arithmetic ops, logical ops and inc/dec ops. So its not just DAA to fix but all other interesting instructions.
2. The original Intel 8080 Assembly Language manual documents these flag settings sparsely and wrongly.
3. The later Intel 8080 and 8085 manual does a slightly better job, it does mention difference between 8080 and 8085 setting of AUX. It does document how AUX is set for more instructions. BUT not all ! It contradicts the earlier manual.
4. Pretty much all 8080/8085 simulators I have found on the net have had bugs with DAA !
5. The z80 treats these flags differently again.
I do not have a real CPU to test against. I have only be making checks against the SIMH Altairz80 simulator in 8080 mode.
Seems I have to decide between 8080 and 8085 and be sure to get at least that one right.
Testing DAA against a real CPU is a HUGE task. One has to check many many combinations of DAA with adds/subtracts, and/ors/xors, increment/decrement.......with all kind of operand values.....
I'm shooting for 8085 compatibility for now because: I do actually have an 8085 chip which will be set working one day. I can "borrow" the flag setting logic from the GNU 8085 simulator[noparse]:)[/noparse]
Dr_A, or anyone, attached is the 8080 cpu test source from MICROCOSM ASSOCIATES I'm using. I have made minor changes to get it to assemble with M80. Just rename to .MAC. If you are willing to try it you will hace to change the character output routine to work on your system.
I put a jump around the DAA test JMP NODAA do you can see where the problem is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Where
Register Meaning Value
C Carry flag (0/1)
Z Zero flag (0/1)
M Minus flag (0/1)
E Even parity flag (0/1)
I lnterdigit carry (0/1)
A Accumulator (0-FF)
B BC register pair (0-FFFF)
D DE register pair (0-FFFF)
H HL register pair (0-FFFF)
S Stack pointer (0-FFFF)
P Program counter (0-FFFF)
Got some more code?
BTW that test8080 program compiles but doesn't display the signon message. I suspect it is going to need some work eg .mac files don't need an 0rg 0100 as it is assumed but ones that use asm in cp/m did need an org 0100. Have you got the original source by any chance?
Post Edited (Dr_Acula (James Moxham)) : 1/18/2009 1:51:26 PM GMT
@humanoido: Thanks. I'm amazed I got this far myself. It was an interesting puzzle, though I do wonder what you, or anyone, would do with a tiny basic like that.
@Dr_A: Thanks again for pointing me at DDT I hadn't taken the time to find out how to use it before. Turns out DDT runs just fine on PropAlatair so it makes quick checks much easier.
As for more code, not yet, but I was thinking to create a little program that exercises all the instructions that affect the AUX flag and reports what happens. This should be able to run on any 8080 like cpu or simulator so that we can see what is what.
I had to make some changes to get it to assemble under M80:
1. It uses STR 'bla bla bla' which I changed to DB 'bla bla bla'
2. It uses MVI L,(TEMP0&0FFH) to get the low byte of a memory address, I changed to MVI L,(TEMP0 AND 0FFH)
3. It uses MVI H,(TEMP0/0FFH) to get the high byte of memory address, I changed to MVI H,(TEMP0 / 256)
4. There is a missing ":" in the declaration of TEMP2
5. I added ASEG at the beginning.
I had to change the character output routine it uses as it goes straight to the 8051 hardware instead of using BDOS. Suggest you change it to us BDOS.
By the way did anyone notice: The fact that DDT runs on PropAltair makes the propeller a self hosting development environment for the Propeller !!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ahhhgg, this is awfull, there are six places in the emulator to add one long each to fix the 8080 AUX flag setting and only ONE free long in my COG !!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Nooooo! You can't run out of space in the prop now?! Not when it is so close.
Anyway, getting DDT working is going to help a lot. You can type in short programs using a (assemble) and trace them one step at a time and watch registers change. Saves compiling each time. I presume you have links to the instruction manual http://www.unix4fun.org/z80pack/cpm2/ch4.htm
One thing you will be able to do with a real board (it should be in customs by now) is to compare the simulator with running ddt on a real board.
Actually after another sleepless night pondering how to save COG space I came up with a cunning and devious plan.
With out going into too much detail. Currently I have a lump of PASM that is an ALU. The intention was to save COG space by having it common to all arithmetic and logic ops. This ALU has configurable instructions to determine it's operand sources and result destination. It also has a flag input to cause it to set 8080 flags differently for arithmetic or logical ops. These "parameters" have to be set by the opcode handlers prior to jumping to the ALU. The parameters being determined by decoding instruction fields.
Turns out all this opcode field decoding and ALU parameter setting makes for a lot of PASM instructions. And makes the whole code especially the ALU hard to understand.
Now, it occurred to me that I already have a fast LMM implementation to handle some lesser used ops that previously did not fit in COG. What if I moved all the arithmetic and logic ops out to LMM code? Sounds slower than PASM right?
Perhaps not, by getting rid of a shared ALU and jumping to some LMM that only handles one op, say ORA B, straight from the dispatch table the opcode handler becomes much short and in line, the overhead of it being LMM is about the same as the overhead of setting up the old ALU params. Perhaps it's even faster.
@Dr_D: I found a DDT manual and all is working well, currently I compare execution with the Altairz80 simulator in 8080 mode.
@Cluso99: Will the debugger handle reverse execution order LMM ? Without driving me nuts !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, my debugger is just a pasm instruction debugger, so it doesn't really know anything about anything except executing a single pasm instruction. But I don't think this is what you actually are asking, and it is not a true LMM machine although this is how it actually works.
However, I have a better idea for you that may work. In my ClusoInterpreter I made decoding much faster and shorter by having a vector table in hub ram. You are welcome to use this method. See the published (not working, but the decoding does) ClusoInterpreter or PM me with an email address and I'll email it to you and anything else you may require. I also did a fast compact overlay loader which is faster than LMM.
BTW I am really impressed at what you have achieved - but I dare not look at it or I =WILL= get distracted
PS. I can get you 4 more instructions at $1F0-1F3 and 1 or 2 variables at $1F5 and $1f7 (from memory) if that helps :-)
Thanks Cluso, Your debugger sounds interesting, I'll give it a check out if I get really stuck.
Just now I do have a vector (dispatch) table in HUB RAM. My "dispatcher" uses it to select PASM routines for op code handler OR it it can execute LMM blocks. Basically the table is a list of words with PASM addresses in COG or LMM addresses in RAM. The dispatcher checks if the looked up address is >= 512 and starts LMM if so instead of jumping to PASM.
Problem is if you do a straight decode using the dispatch table into PASM routine that's 256 routines. So if they were only one LONG + a jump back to dispatch loop the COG would be full.
To get around this I started pointing (in the table) many similar opcodes to the same handler routine which would decode some fields of the op code and do the op. So for example 64 MOV instructions can be handled by one handler of 10 LONGS.
Trouble is when you do that with arith/logic ops the decoding gets long and tortuous.
Other big, slow less used ops (Like DAA is almost never used.) I put into LMM.
Overlays, hmm, interesting idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: I'm using LMM in one of my projects and I'm surprised how well it does. I was using some routine to handle jumping... but add and sub directly from the PC works quite well, the range is +/63. Some macro here would surely help. A table is a good way of squeezing speed out of some decoding like yours. For a slow (but very compact) example you have the spin interpreter, a marvelous piece of code. May be a table in ROM would have helped ?
Edit: After some trial, I discovered that the range is actually +/- 63 instructions :-(, not 512 as I thought, well...
Heater: My vector table is in hub and it is quick. I can house 3 vectors and 5 bits per vector in 1 long. Allows for multiple routines to be called per vector.
Here is the vector code section I use in the ClusoInterpreter
loop
mov x,#0 'reset x
rdbyte op,pcurr 'get opcode
add pcurr,#1
mov a,op 'preset a (for mathop)
test op,#%01 wz 'get flags
test op,#%10 wc '(note varop requires c=1)
mov vector,op 'get the offset (bytecode op)
vector1 shl vector,#2 'convert to longs (*4)
add vector,vector_base 'add the hub base address
rdlong vector,vector 'get the vector_table entry
jmpret popx_ret,vector 'indirect call to 1st vector (return address in pop_ret=vector_ret)
vector2 shr vector,#9
jmpret popx_ret,vector 'indirect call to 2nd vector (return address in pop_ret=vector_ret)
vector3 shr vector,#9
jmpret popx_ret,vector 'indirect call to 3rd vector (return address in pop_ret=vector_ret)
jmp $ 'never gets here!!! (can save this instr) '<===
'
vector_base long 0-0 'base of vector_table
vector long 0-0 'vector(s)
And here are bits of the vector table in hub
long j5_23 <<9+ popyx ' 17 00010111 STRCOMP(stringa,stringb) 2 1
long i_WRBYTE <<18+ j6_012 <<9+ popayx ' 18 6 00011000 BYTEFILL(start,value,count) 3
long i_WRWORD <<18+ j6_012 <<9+ popayx ' 19 00011001 WORDFILL(start,value,count) 3
long i_WRLONG <<18+ j6_012 <<9+ popayx ' 1A 00011010 LONGFILL(start,value,count) 3
long i_bin +i_ROR <<18 +math_E0 <<9 +math_bin '$041 E0 00000 ROR 1st -> 2nd b -> ->= rotate_right
long i_bin +i_ROL <<18 +math_E0 <<9 +math_bin '$049 E1 00001 ROL 1st <- 2nd b <- <-= rotate_left
long i_bin +i_SHR <<18 +math_E0 <<9 +math_bin '$051 E2 00010 SHR 1st >> 2nd b >> >>= shift_right
Hurray !!! The pesky DAA instruction is now working!! Daa, Daa, Daa....
See attached screen shot running a CPU test under CP/M. All tests OK.
Had to fix ALL the other logic ops (ANDa, ORs and XORS) to do this, which meant moving them to LMM.
Suprisingly that does not cost much in speed after "in lining" the code.
I will not attach this code yet as I want to clean it up some more.
Thanks for all your suggestions, I will look into them when I have a mo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
1. Simulator "main" does some init then starts CPU, is actually free for use after that sitting in "repeat".
2. The 8080 emulation.
3. I/O subsystem, Emulates anything on the other end of CPU IN/OUT instructions.
currently: console in, console out, 8 floppy disks on SD card and driving the Prop Demo Boards LEDS.
4. PC_Keyboard for listening to PropTerminal.
5. PC_Text for talking to Prop terminal.
6. sdspiqasm - The low level SD card driver.
7. Free.
8. Free.
Running a 24K byte CP/M system (God how I wish I had that in 1979!) my HUB RAM is
full 61 longs left. The emulator COG is full 7 LONGS free!
There are many ways to go from here:
The simulator main COG could be combined with the I/O cog.
PC_Keyboard can be replaced by a real keyboard driver.
PC_Text can be replaced by a TV or VGA driver, if we use external RAM for CP/M.
PC_XX could be replace with full duplex serial for use with ProComm, which is what I want to next.
Now that the 8080 logical operation seems to be pinned down accurately I'd like to go for a
multi COG emulator, for speed, but I'm going to leave that for now and start trying to get DrAcula's N8VEM CP/M
board to use a Propeller for it's I/O devices and disks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
So heater is the plan to use 2 props, one for the PropAltair and one for the Video Terminal (VGA/TV & PS2 Keyboard) and communicate serially [noparse][[/noparse]ProComm] ?
Well there are a couple of plans[noparse]:)[/noparse]
1. Add external RAM to a Prop and run the emulator and TV and keyboard and SD. A full system on a chip. If there are enough pins etc.
2. I really like the idea of using a serial line to PropComm. Preferably with external RAM for the emulator but it rans without anyway.
3. Given that a Prop with external RAM then has a "bus interface" it could also include an IO/M line to select I/O devices
in which case it might be cool to use the second Prop on the "IO" bus where it emulates serial port chips etc in a simple way
perhaps a modified version of PropComm with VT100 emulation. Perhaps also including the SD
card driver as PropComm has that anyway.
4. One day we may have a Prop/CPLD/RAM board from Leon which would make all this very neat.
In the mean time there is a plan to add a Propeller to the N8VEM CP/M computer project (Dr_Acula and co), which uses a real Z80 chip, to
implement peripheral devices. Replacing all/most of them thus making for a really simple real CP/M machine.
I will be concentrating on N8VEM next as Dr_Acula has been kind enough to send me a board. But I'm pondering if the N8VEM
can be combined (about same as) option 3 above.
Decisions, decisions....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Outside of a couple VT100 emulation issues. (I'm adding VT52 as well)
PropCOMM is about as smooth as it can be for use with a CP/M board, Propeller or otherwise.
At present the system is Xmodem transfer into the CP/M side, then launch.
This works, but honestly could be better implemented with some type of direct access to
the to the SD card from CP/M side. (A little outside of my abilities at present)
Personally, I'm just waiting for one of our resident wizards to create an onboard compiler
so we can create code and compile without the use of a PC. [noparse]:)[/noparse] As I see it, we're pretty close.
I like the idea of 2 props, one doing the emulation and one doing the terminal and I/Os if required. The emulation prop needs the SD card for the disk and CP/M. It is fairly easy to stack 2 prop proto boards. Only need 4 wires: +V & GND, Tx & Rx to join them.
This way, the emulation prop could do the PropAltair, ZX81, Apple or C64, etc. Just change the SD card
Once you use a CPLD, may as well go the whole hog and do the complete cpu and terminal in a single fpga such as a spartan 3 (it's been done for a number of retros). But that takes the fun away from usng the Prop :-(
OBC: Does PropComm have just a version with VGA + PS2 Keyboard + VT100 + Serial (i.e. A standalone video terminal running on a Prop)? (I think you may have gone past this point)
I haven't added the extended VT100 stuff to the TV version yet.
Doug is working on an 80 column, color TV driver, so I'm waiting to see what he comes up with.
Honestly, I'd rather he spent his time on the 6502 emu stuff. [noparse]:)[/noparse]
@heater, sorry, looks like I've gone and hijacked your thread..
Point additional PropCOMM questions to my thread. [noparse]:)[/noparse]
OBC, never mind the thread hijacking. There seems to be some symbiosis going on here. For sure it's in my plans to have a two Prop stand alone CP/M system with PropComm.
As I'm done with trying out old BASICs future PropAltair developments will go back onto the CPM/Propeller thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Guess I could have just used the 8085 core from opencores,org. FPGAs are something else I'd love to have the time to get in to. Someone here is creating a propeller in verilog so perhaps one day there will be an 8080 emulated on a propeller implemented in an FPGA[noparse]:)[/noparse]
I don't think using a weeny small cheap CPLD as glue between a Prop some RAM and some peripherals compares to implementing an 8080 on FPGA. Not sure but surely an FPGA big enough to implement an 8080 would be much more expensive and you'd still need the RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
My Spartan 3A·(Avnet)·board has external ram end flash. However, the Spartan 3A has 56Kb of distributed ram and 360Kbits of block ram within the XC3S400A fpga. Some of this may get used in the cpu design. I am using the 512x36 blocks as 512x32 (dual port) for the cog ram.
Gosh that is going back in time. I seem to remember that at some point we had 4K BASIC working. Of course just now I can't find it in the forum anywhere.
I've just been through the old PropAltair thread without spotting it. If I have time I'll scour my old PC and try to find it for you later today.
Or perhaps someone has a book mark to it.
I also seem to remember that the MITS BASICS stopped working in the later ZiCog Z80 emulators as they relied on 8080 flag operation or some such.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
Here is what I found so far:
1. The DAA instruction is dependent on the setting of the Auxiliary Carry flag (half carry) by previous instructions. Namely arithmetic ops, logical ops and inc/dec ops. So its not just DAA to fix but all other interesting instructions.
2. The original Intel 8080 Assembly Language manual documents these flag settings sparsely and wrongly.
3. The later Intel 8080 and 8085 manual does a slightly better job, it does mention difference between 8080 and 8085 setting of AUX. It does document how AUX is set for more instructions. BUT not all ! It contradicts the earlier manual.
4. Pretty much all 8080/8085 simulators I have found on the net have had bugs with DAA !
5. The z80 treats these flags differently again.
I do not have a real CPU to test against. I have only be making checks against the SIMH Altairz80 simulator in 8080 mode.
Seems I have to decide between 8080 and 8085 and be sure to get at least that one right.
Testing DAA against a real CPU is a HUGE task. One has to check many many combinations of DAA with adds/subtracts, and/ors/xors, increment/decrement.......with all kind of operand values.....
I'm shooting for 8085 compatibility for now because: I do actually have an 8085 chip which will be set working one day. I can "borrow" the flag setting logic from the GNU 8085 simulator[noparse]:)[/noparse]
Dr_A, or anyone, attached is the 8080 cpu test source from MICROCOSM ASSOCIATES I'm using. I have made minor changes to get it to assemble with M80. Just rename to .MAC. If you are willing to try it you will hace to change the character output routine to work on your system.
I put a jump around the DAA test JMP NODAA do you can see where the problem is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
ddt
DDT VERS 2.2
-a0100
0100 nop
0101 ora a
0102 nop
0103 daa
0104 nop
0105
-t
C0Z0M0E0I0 A=00 B=0000 D=0000 H=0000 S=0100 P=0100 NOP *0101
-t
C0Z0M0E0I0 A=00 B=0000 D=0000 H=0000 S=0100 P=0101 ORA A*0102
-t
C0Z1M0E1I0 A=00 B=0000 D=0000 H=0000 S=0100 P=0102 NOP *0103
-t
C0Z1M0E1I0 A=00 B=0000 D=0000 H=0000 S=0100 P=0103 DAA *0104
-t
C0Z1M0E1I0 A=00 B=0000 D=0000 H=0000 S=0100 P=0104 NOP *0105
-
Where
Register Meaning Value
C Carry flag (0/1)
Z Zero flag (0/1)
M Minus flag (0/1)
E Even parity flag (0/1)
I lnterdigit carry (0/1)
A Accumulator (0-FF)
B BC register pair (0-FFFF)
D DE register pair (0-FFFF)
H HL register pair (0-FFFF)
S Stack pointer (0-FFFF)
P Program counter (0-FFFF)
Got some more code?
BTW that test8080 program compiles but doesn't display the signon message. I suspect it is going to need some work eg .mac files don't need an 0rg 0100 as it is assumed but ones that use asm in cp/m did need an org 0100. Have you got the original source by any chance?
Post Edited (Dr_Acula (James Moxham)) : 1/18/2009 1:51:26 PM GMT
humanoido
@Dr_A: Thanks again for pointing me at DDT I hadn't taken the time to find out how to use it before. Turns out DDT runs just fine on PropAlatair so it makes quick checks much easier.
As for more code, not yet, but I was thinking to create a little program that exercises all the instructions that affect the AUX flag and reports what happens. This should be able to run on any 8080 like cpu or simulator so that we can see what is what.
I got the original test program from here: www.classiccmp.org/dunfield/r/test.asm. That guy has a lot of good CP/M material.
I had to make some changes to get it to assemble under M80:
1. It uses STR 'bla bla bla' which I changed to DB 'bla bla bla'
2. It uses MVI L,(TEMP0&0FFH) to get the low byte of a memory address, I changed to MVI L,(TEMP0 AND 0FFH)
3. It uses MVI H,(TEMP0/0FFH) to get the high byte of memory address, I changed to MVI H,(TEMP0 / 256)
4. There is a missing ":" in the declaration of TEMP2
5. I added ASEG at the beginning.
I had to change the character output routine it uses as it goes straight to the 8051 hardware instead of using BDOS. Suggest you change it to us BDOS.
By the way did anyone notice: The fact that DDT runs on PropAltair makes the propeller a self hosting development environment for the Propeller !!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Anyway, getting DDT working is going to help a lot. You can type in short programs using a (assemble) and trace them one step at a time and watch registers change. Saves compiling each time. I presume you have links to the instruction manual http://www.unix4fun.org/z80pack/cpm2/ch4.htm
One thing you will be able to do with a real board (it should be in customs by now) is to compare the simulator with running ddt on a real board.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
With out going into too much detail. Currently I have a lump of PASM that is an ALU. The intention was to save COG space by having it common to all arithmetic and logic ops. This ALU has configurable instructions to determine it's operand sources and result destination. It also has a flag input to cause it to set 8080 flags differently for arithmetic or logical ops. These "parameters" have to be set by the opcode handlers prior to jumping to the ALU. The parameters being determined by decoding instruction fields.
Turns out all this opcode field decoding and ALU parameter setting makes for a lot of PASM instructions. And makes the whole code especially the ALU hard to understand.
Now, it occurred to me that I already have a fast LMM implementation to handle some lesser used ops that previously did not fit in COG. What if I moved all the arithmetic and logic ops out to LMM code? Sounds slower than PASM right?
Perhaps not, by getting rid of a shared ALU and jumping to some LMM that only handles one op, say ORA B, straight from the dispatch table the opcode handler becomes much short and in line, the overhead of it being LMM is about the same as the overhead of setting up the old ALU params. Perhaps it's even faster.
@Dr_D: I found a DDT manual and all is working well, currently I compare execution with the Altairz80 simulator in 8080 mode.
@Cluso99: Will the debugger handle reverse execution order LMM ? Without driving me nuts !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, my debugger is just a pasm instruction debugger, so it doesn't really know anything about anything except executing a single pasm instruction. But I don't think this is what you actually are asking, and it is not a true LMM machine although this is how it actually works.
However, I have a better idea for you that may work. In my ClusoInterpreter I made decoding much faster and shorter by having a vector table in hub ram. You are welcome to use this method. See the published (not working, but the decoding does) ClusoInterpreter or PM me with an email address and I'll email it to you and anything else you may require. I also did a fast compact overlay loader which is faster than LMM.
BTW I am really impressed at what you have achieved - but I dare not look at it or I =WILL= get distracted
PS. I can get you 4 more instructions at $1F0-1F3 and 1 or 2 variables at $1F5 and $1f7 (from memory) if that helps :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
Post Edited (Cluso99) : 1/19/2009 7:54:21 AM GMT
Just now I do have a vector (dispatch) table in HUB RAM. My "dispatcher" uses it to select PASM routines for op code handler OR it it can execute LMM blocks. Basically the table is a list of words with PASM addresses in COG or LMM addresses in RAM. The dispatcher checks if the looked up address is >= 512 and starts LMM if so instead of jumping to PASM.
Problem is if you do a straight decode using the dispatch table into PASM routine that's 256 routines. So if they were only one LONG + a jump back to dispatch loop the COG would be full.
To get around this I started pointing (in the table) many similar opcodes to the same handler routine which would decode some fields of the op code and do the op. So for example 64 MOV instructions can be handled by one handler of 10 LONGS.
Trouble is when you do that with arith/logic ops the decoding gets long and tortuous.
Other big, slow less used ops (Like DAA is almost never used.) I put into LMM.
Overlays, hmm, interesting idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Edit: After some trial, I discovered that the range is actually +/- 63 instructions :-(, not 512 as I thought, well...
Post Edited (Ale) : 1/19/2009 1:32:06 PM GMT
Here is the vector code section I use in the ClusoInterpreter
loop mov x,#0 'reset x rdbyte op,pcurr 'get opcode add pcurr,#1 mov a,op 'preset a (for mathop) test op,#%01 wz 'get flags test op,#%10 wc '(note varop requires c=1) mov vector,op 'get the offset (bytecode op) vector1 shl vector,#2 'convert to longs (*4) add vector,vector_base 'add the hub base address rdlong vector,vector 'get the vector_table entry jmpret popx_ret,vector 'indirect call to 1st vector (return address in pop_ret=vector_ret) vector2 shr vector,#9 jmpret popx_ret,vector 'indirect call to 2nd vector (return address in pop_ret=vector_ret) vector3 shr vector,#9 jmpret popx_ret,vector 'indirect call to 3rd vector (return address in pop_ret=vector_ret) jmp $ 'never gets here!!! (can save this instr) '<=== ' vector_base long 0-0 'base of vector_table vector long 0-0 'vector(s)And here are bits of the vector table in hub
Hope this may help
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
See attached screen shot running a CPU test under CP/M. All tests OK.
Had to fix ALL the other logic ops (ANDa, ORs and XORS) to do this, which meant moving them to LMM.
Suprisingly that does not cost much in speed after "in lining" the code.
I will not attach this code yet as I want to clean it up some more.
Thanks for all your suggestions, I will look into them when I have a mo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Now you have it working, how many cogs are you using and what are they used for?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
1. Simulator "main" does some init then starts CPU, is actually free for use after that sitting in "repeat".
2. The 8080 emulation.
3. I/O subsystem, Emulates anything on the other end of CPU IN/OUT instructions.
currently: console in, console out, 8 floppy disks on SD card and driving the Prop Demo Boards LEDS.
4. PC_Keyboard for listening to PropTerminal.
5. PC_Text for talking to Prop terminal.
6. sdspiqasm - The low level SD card driver.
7. Free.
8. Free.
Running a 24K byte CP/M system (God how I wish I had that in 1979!) my HUB RAM is
full 61 longs left. The emulator COG is full 7 LONGS free!
There are many ways to go from here:
The simulator main COG could be combined with the I/O cog.
PC_Keyboard can be replaced by a real keyboard driver.
PC_Text can be replaced by a TV or VGA driver, if we use external RAM for CP/M.
PC_XX could be replace with full duplex serial for use with ProComm, which is what I want to next.
Now that the 8080 logical operation seems to be pinned down accurately I'd like to go for a
multi COG emulator, for speed, but I'm going to leave that for now and start trying to get DrAcula's N8VEM CP/M
board to use a Propeller for it's I/O devices and disks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
1. Add external RAM to a Prop and run the emulator and TV and keyboard and SD. A full system on a chip. If there are enough pins etc.
2. I really like the idea of using a serial line to PropComm. Preferably with external RAM for the emulator but it rans without anyway.
3. Given that a Prop with external RAM then has a "bus interface" it could also include an IO/M line to select I/O devices
in which case it might be cool to use the second Prop on the "IO" bus where it emulates serial port chips etc in a simple way
perhaps a modified version of PropComm with VT100 emulation. Perhaps also including the SD
card driver as PropComm has that anyway.
4. One day we may have a Prop/CPLD/RAM board from Leon which would make all this very neat.
In the mean time there is a plan to add a Propeller to the N8VEM CP/M computer project (Dr_Acula and co), which uses a real Z80 chip, to
implement peripheral devices. Replacing all/most of them thus making for a really simple real CP/M machine.
I will be concentrating on N8VEM next as Dr_Acula has been kind enough to send me a board. But I'm pondering if the N8VEM
can be combined (about same as) option 3 above.
Decisions, decisions....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
PropCOMM is about as smooth as it can be for use with a CP/M board, Propeller or otherwise.
At present the system is Xmodem transfer into the CP/M side, then launch.
This works, but honestly could be better implemented with some type of direct access to
the to the SD card from CP/M side. (A little outside of my abilities at present)
Personally, I'm just waiting for one of our resident wizards to create an onboard compiler
so we can create code and compile without the use of a PC. [noparse]:)[/noparse] As I see it, we're pretty close.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
This way, the emulation prop could do the PropAltair, ZX81, Apple or C64, etc. Just change the SD card
Once you use a CPLD, may as well go the whole hog and do the complete cpu and terminal in a single fpga such as a spartan 3 (it's been done for a number of retros). But that takes the fun away from usng the Prop :-(
OBC: Does PropComm have just a version with VGA + PS2 Keyboard + VT100 + Serial (i.e. A standalone video terminal running on a Prop)? (I think you may have gone past this point)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
Post Edited (Cluso99) : 1/19/2009 5:54:30 PM GMT
One has the PropDOS additions, while the other does not.
http://forums.parallax.com/showthread.php?p=772078
I haven't added the extended VT100 stuff to the TV version yet.
Doug is working on an 80 column, color TV driver, so I'm waiting to see what he comes up with.
Honestly, I'd rather he spent his time on the 6502 emu stuff. [noparse]:)[/noparse]
@heater, sorry, looks like I've gone and hijacked your thread..
Point additional PropCOMM questions to my thread. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Check out: Protoboard Introduction , Propeller Cookbook 1.4 & Software Index
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
As I'm done with trying out old BASICs future PropAltair developments will go back onto the CPM/Propeller thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Postedit: Sorry, here is the link· http://www.fpgaarcade.com/library.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
Post Edited (Cluso99) : 1/20/2009 9:20:11 AM GMT
Guess I could have just used the 8085 core from opencores,org. FPGAs are something else I'd love to have the time to get in to. Someone here is creating a propeller in verilog so perhaps one day there will be an 8080 emulated on a propeller implemented in an FPGA[noparse]:)[/noparse]
I don't think using a weeny small cheap CPLD as glue between a Prop some RAM and some peripherals compares to implementing an 8080 on FPGA. Not sure but surely an FPGA big enough to implement an 8080 would be much more expensive and you'd still need the RAM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
btw for fpga you'll need the ram + flash so it'll be even more expensive! lol
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
My Spartan 3A·(Avnet)·board has external ram end flash. However, the Spartan 3A has 56Kb of distributed ram and 360Kbits of block ram within the XC3S400A fpga. Some of this may get used in the cpu design. I am using the 512x36 blocks as 512x32 (dual port) for the cog ram.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Prop Tools under Development or Completed (Index)
http://forums.parallax.com/showthread.php?p=753439
My cruising website http://www.bluemagic.biz
Post Edited (Cluso99) : 1/20/2009 9:30:06 AM GMT
Welcome to the forum.
Gosh that is going back in time. I seem to remember that at some point we had 4K BASIC working. Of course just now I can't find it in the forum anywhere.
I've just been through the old PropAltair thread without spotting it. If I have time I'll scour my old PC and try to find it for you later today.
Or perhaps someone has a book mark to it.
I also seem to remember that the MITS BASICS stopped working in the later ZiCog Z80 emulators as they relied on 8080 flag operation or some such.