@Bamse: The pins are mostly arbitrary, and depending on what features of the 6502 you're willing to give up you can free up some extra pins (for instance, you could drop INT or Sync and Rdy). The only pins that have to stay the same are the 8 data bits on Propeller pin 0 to pin 7, and the clock on pin 8. That's because I take advantage of the fact that I can use constants $FF and $100 in assembly to write constants to those pins directly in dira and outa.
I think that I'm going to try and bread board this and add VGA.
Or maybe get the VGA/keyboard connector for the Proto board since it seem to use P16 to P23...
I'm sorry to say that I won't have time to look into this until next year though...
Thanks again for doing the awesome 6502 project...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
I've been working through a proto-type demo PASM 6502. Got it running today. At first glance it's over 1 Mhz, so that's favorable for emulation. Lots to do yet, but if you want to see the count go way faster, snag this set of files.
The little blob in the corner is a write to the screen for comparing a value. Quick 'n dirty debug.
Edit: I've learned some stuff. One of the biggies is figuring out quick 'n dirty ways to debug. When it's something like this, you don't get much. Probably why people buy or write debuggers. What I ended up doing was writing a value to spin, which can be seen on the screen as a character, or interesting blob, depending on what it is. In the PASM code, write the state of things to the screen at times. That's enough to work through test cases.
The implications of what you are doing are just amazing.
I see VCS clone in the near future.. Maybe even an Apple][noparse][[/noparse] clone.. [noparse]:)[/noparse]
Now, If I can just get Steve Jobs to read his email and release the apple2 roms. [noparse]:)[/noparse]
Jetfire, a full on 6502 is probably gonna take more than one COG, unless somebody some where has some wicked way to fit the instructions into just one, at speed. If this happens, then the regs should be in the COG. It's a nice notch faster that way!
OBC, Apple ][noparse][[/noparse] roms are all over the place. I've snagged an emulator, roms and such already. Wrote a coupla Applesoft basic toys last night. It's still in my brain after all this time! God, that was a slow *** basic. The integer basic was way faster, though spartan. Anyway, some low-res basic games would probably fit in the Propeller RAM. Simulate a 4 or 8 K Apple maybe.
On a somewhat related topic, I love the Apple machines almost as much as I do Atari and C64. (and I lean Atari :P BTW...) The documentation that came with them was excellent, and the machine was just open. Card slots there for the hacking. In fact, a Propeller on a card, in an Apple ][noparse][[/noparse] case would just rock!! Hmmm ... maybe I'm gonna have to E-bay this year and score one. The ROM listing was included, commented too! That taught me and my High School buddies Assembly language back then. We just looked at the ROM listing, hand assembled our own codes, and ran them from the monitor. The little mini assembler in there helped out big, when we found out about the thing. Apples were not the greatest in terms of speed, but in terms of utility, remain unmatched among 8 bitters!
No Probs potatohead, anytime [noparse]:)[/noparse]
Never played with an Apple ][noparse][[/noparse] they were never really big over here.
maybe I'll grab an emu and have a play.
Yeah, I think the Apple has a similar feel as the speccy does with games. Both had bitmap graphics, no sprites and a modest CPU. You'll probably like it, and if you go early, you will find a lot of classic firsts on the Apple.
That machine is where it all started for me. Schools had 'em, so that's where the computing and gaming happened. BTW: The Robotron port for Apple is just awesome. Wouldn't expect that, but it is.
Thanks for that. I'll plop it in there on the next pass. There's a bug in BNE too. Works for backward branches, but won't work for forward ones. Typed in TEMP, when it should be _ALU. That one is tagged too, just FYI.
Using cog based registers instead of hub based registers could make some commands much smaller. Since the jump table uses longs instead of bytes you could put in other commands than just jmp.
For example, for a9 you would put "mov A, PC" into the jump table command, the "_jump_instruction" is followed by a PC incrementer, it goes into "done" and loops back for the next opcode.
This means that a9, a2, and a0 would go from 12 longs to 0 longs in the cog. I don't think you can make it any better.
This really only makes sense if you can put everything in one cog. If you need more than one, the rest of the opcode handling would be in another cog, the registers would be written out to the hub, then read back in when the second cog finishes.
...or have all cogs fetching the opcode at the same time (well, in HUB sequence), and only the one containing the instruction code does anything. Use two or three this way, syncing after every instruction.
At the target speed, we have 17 instructions (give or take a few, depending on 80mhz clock vs 96 mhz), per 6502 clock cycle. The one byte instructions are gonna be tight. The longer ones at 7 cycles will be fine. Each HUB fetch equates to roughly 4 instructions, to help compute the cost of things.
That's a really great idea for using the jmp table!
I worked to complete all the LDA opcodes. They aren't tested, and might be wrong. I think that I got zero page wrapping correct. From what I can tell, zero page and immediate would be the same.
' $B5 LDA
_LDA_ZP_X rdbyte _TEMP, _PC 'get PC
add _PC, #1 'update PC
rdbyte _X, X 'get X
add _TEMP, _X 'add to get address
and _TEMP, #%11111111 'keep only 8 bits, wrap around
rdbyte _A, _TEMP 'load A from address
wrbyte _A, A 'write A
jmp #done
' $AD LDA
_LDA_ABS rdbyte _TEMP, _PC 'get low address
add _PC, #1
rdbyte _TEMP_A, _PC 'get high address
shl _TEMP_A, #8 'combine low and high
add _TEMP, _TEMP_A
rdbyte _A, _TEMP 'load A from address
add _PC, #1 'update PC
wrbyte _A, A 'write A
jmp #done
' $B9 LDA
_LDA_ABS_Y rdbyte _Y, Y 'get Y
rdbyte _TEMP, _PC 'get low address
add _PC, #1
add _TEMP, _Y 'add Y to address
rdbyte _TEMP_A, _PC 'get high address
shl _TEMP_A, #8 'combine low and high
add _TEMP, _TEMP_A
rdbyte _A, _TEMP 'load A from address
add _PC, #1 'update PC
wrbyte _A, A 'write A
jmp #done
' $A1 LDA
_LDA_IND_X rdbyte _TEMP_A, _PC 'get PC
add _PC, #1 'update PC
rdbyte _X, X 'get X
add _TEMP_A, _X 'add to get address
and _TEMP_A, #%11111111 'keep only 8 bits, wrap around
rdbyte _TEMP, _TEMP_A 'get low address
add _TEMP_A, #1
rdbyte _TEMP_A, _TEMP_A 'get high address
shl _TEMP_A, #8 'combine low and high
add _TEMP, _TEMP_A
rdbyte _A, _TEMP 'load A from address
wrbyte _A, A 'write A
jmp #done
' $B1 LDA
_LDA_IND_Y rdbyte _TEMP_A, _PC 'get PC
add _PC, #1 'update PC
rdbyte _Y, Y 'get Y
add _TEMP_A, _Y 'add to get address
rdbyte _TEMP, _TEMP_A 'get low address
add _TEMP_A, #1
rdbyte _TEMP_A, _TEMP_A 'get high address
shl _TEMP_A, #8 'combine low and high
add _TEMP, _TEMP_A
rdbyte _A, _TEMP 'load A from address
wrbyte _A, A 'write A
jmp #done
From the current code it looks like the Z flag is being stored in FR. What is the plan for storing flags?
That's one of the next items on the list! This one and address translation are biggies.
Here's a quick blurb on the flags:
The Processor Status Flags allow your program to control/monitor the various modes of processor operation. Here's a detailed description of their functions.
N
The Negative flag reflects the sign (+ or -) of a value in the Accumulator, X Index or Y Index. N will be affected whenever the MSb (bit 7) * of A, X or Y changes. N will be set (1) ** if the MSb is set and clear (0) if the MSb is clear. N is affected by all these instructions: ADC AND ASL BIT CMP CPX CPY DEC DEX DEY EOR INC INX INY LDA LDX LDY LSR ORA PLA PLP ROL ROR RTI SBC TAX TAY TSX TXA TXS TYA
V
The oVerflow flag indicates a carry from bit 6 to bit 7 of A. It is mostly used in signed arithmetic where bit 7 is the sign flag of a value. V is affected by: ADC BIT CLV PLP RTI SBC
-
- is not really flag but is an unused bit of the Processor Status Register. - is bit 5 of P and is always set (1)
B
The Break flag is used to indicate that a program-generated interrupt has occured. If the source of the interrupt is a BRK instruction then B is set. Any interrupt caused by the 6502 IRQ or NMI inputs automatically clears B. PHP also causes B to be set although I'm not sure why (I welcome remarks from anyone who understands this better!)
D
The Decimal flag is used to enable 6502 Decimal mode arithmetic. Decimal mode is enabled when D is set; binary mode is enabled when D is clear. D is set by SED and cleared by CLD but is also affected by PLP and RTI.
I
The Interrupt Disable flag is used to mask interrupts from the 6502 IRQ input and is ideal for use in interrupt handler routines. It has no effect on program interrupts generated by BRK. Use CLI to allow a program to be interrupted by IRQ and SEI to disallow interrupts from IRQ. I is set by BRK and is also affected by PLP and RTI.
Z
The Zero Flag is set whenever an operation causes a result of 0 (zero) in A, X or Y. Z is affected by all these instructions: ADC AND ASL BIT CMP CPX CPY DEC DEX DEY EOR INC INX INY LDA LDX LDY LSR ORA PLA PLP ROL ROR RTI SBC TAX TAY TSX TXA TYA
C
The Carry flag indicates that the result of a math operation exceeds 8 bits and in this sense it can be thought of as the "ninth" Accumulator bit. C is affected by all these instructions: ADC ASL CLC CMP CPX CPY LSR PLP ROL ROR RTI SBC SEC
Probably should step up and change _FR to _SR to match the 6502 convention. It's really both a place for flags and processor status, like BCD mode.
For a zero operation, we would perform a logical and with the SR and write that back to the hub. Since it's only a byte long, we can use literals in PASM, and constants to setup all the bit operations. (I think!)
CON set_zero = %0000_0010 (need to check if this is bit 2 or bit 7)
if_z and _SR, #set_zero
wrbyte __SR, SR
You may have guessed I'd pop up here from the Prop section looking for any tricks to speed up the 8080 emulator. Had a quick scan through your posts here unfortunately I know very little about the 6502, programmed one briefly on an SBC back in uni a million years ago, so I don't follow every detail.
Seems you did a Spin version first, as I did for the 8080. The Apple ][noparse][[/noparse] plan seems sound enough. How does your PASM emulator go? Is there a blob of code you could show us?
To be honest I've hit a wall with the 8080. Run out of ideas. It's already on it's third major rewrite!
I think about splitting it over two or more COGS from time to time but without actually putting the time in to code it I can't convince myself it would get much faster, what with the overheads of moving registers into HUB RAM and keeping everyone in sync. Perhaps you have some ideas about that that I have missed.
It is possible that using external RAM would actually speed it up as there would be no need to test for reading from RAM or ROM areas or range checking either of them.
Happy New Year All !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
we're splitting it over multiple cogs, keeping the registers external [noparse]:([/noparse] unfortunately, but helps with access to from other cogs, and each cog reads the instruction, and uses a jump table, to run it's code, per cog, so one cog will have the routine the other cogs will have fake routines that just wait for next instruction, once current is complete. that way it's faster than LMM but will take up a little more room than LMM. as we'll need 3 or 4 times the jump tables [noparse]:D[/noparse] but I think the speed increase will be worth it.
want me to have a look at your 8080 emu when I get 5? for optimisation ideas?
Interesting. I did at one point have a version of the 8080 emulator with registers in HUB with the idea at the time that:
a) It might make it easier to access individual registers as bytes and register pairs as words.
b) It's a doddle to then have some kind of breakpoint system and be able to see the registers from "outside".
It was not so fast and I gave it up but perhaps it's time to revisit the whole idea. Also I took it as a challenge, at the time, to get the whole emulation into a single COG with no LMM. Which is possible but the tricks required make it slow again.
I'd love for you, or anyone, to review my efforts. Attached is the actual emulator file. May be tricky to follow if your not familiar with the 8080.
If you'd like to run the whole CP/M system it's version propaltair_2_1.zip on page 4 of the CP/M for Propeller thread.
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes, a) was the other reason for hub access, I was thinking ahead for Z80 if we take it another step [noparse]:D[/noparse] so you can do Hi and Lo register pair accesses really easy [noparse]:)[/noparse]
and b) is the added bonus [noparse]:)[/noparse]
yes i'll take a look, next year rofl [noparse]:)[/noparse] sounds so far away, yet it's only 3 and a half hours away here lol
Happy New Year everyone btw [noparse]:)[/noparse]
All the best for 2009
Nice synergy there! Love it. I don't know all that much about the Z80 either! There were not all that many Z80 machines around where I was.
Heater, so far the approach was to hand assemble some relocatable 6502 code. Write a partial 6502 in SPIN, then PASM that. The demo up thread has the partial chip, running over 1Mhz. That's according to a very thumb in the wind benchmark! Basically, the Atari 400, running at 1.7Mhz, with video DMA happening, counts to 9,999,999 in a little over 3 minutes. This one can do it in under 2. One byte instructions are a bit slow, or right on the edge. Multi-byte ones are running good, PASM instruction count wise.
What's there is missing some stuff that's going to be a challenge for speed. I expected slower on the first pass, so it's all favorable at this point.
We kind of stumbled on the Apple, looking for 6502 code to work from. The ROM is a bit big, but aside from that, the machine is just dead simple. There are text / basic lo-res games that run on a small memory too.
Thanks Jetfire, BTW. Work prevented me from doing anything with this. Because of COG space, it's going to be necessary to have code shared among instructions. I wouldn't code too many more just yet, until that gets sorted.
I'll take a look at you "spud" code when I have a moment, just now family wants to do all kind of new year things....
Sure I did a lot of hand assembling to when I started out.
What ideas do you have for methods to synch up multiple COGs?
I was thinking to have a shared counter in HUB RAM such that:
1. Each cog reads the counter prior to fetching and instruction checking if it has something to do in it's dispatch table.
2. If the dispatch table indicates "nothing for you" the COG sits in a loop waiting for the counter to change.
3. Else there is an op to execute and then increment the counter.
4. Go to 1.
This is nice as there is no "master" COG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Does this mean that if you guys can load the ROMs that it will be possible to
run Applesoft BASIC on the Prop? There are a TON of programs which the
door opens to here.
It's progressing OBC. LOL!! CPU / cog stuff being thought through, video specs and such too. Apple video isn't all that complex. Who knows, maybe we will have the text / low-res screen here to test on in a bit!
Comments
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
parts-man, you up to the challenge?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I think that I'm going to try and bread board this and add VGA.
Or maybe get the VGA/keyboard connector for the Proto board since it seem to use P16 to P23...
I'm sorry to say that I won't have time to look into this until next year though...
Thanks again for doing the awesome 6502 project...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Living on the planet Earth might be expensive but it includes a free trip around the sun every year...
Experience level:
[noparse][[/noparse] ] Let's connect the motor to pin 1, it's a 6V motor so it should be fine.
[noparse][[/noparse] ] OK, I got my resistors hooked up with the LEDs.
[noparse][[/noparse]X] I got the Motor hooked up with the H-bridge and the 555 is supplying the PWM.
[noparse][[/noparse] ] Now, if I can only program the BOE-BOT to interface with he Flux Capacitor.
[noparse][[/noparse] ] I dream in SX28 assembler...
/Bamse
I've been working through a proto-type demo PASM 6502. Got it running today. At first glance it's over 1 Mhz, so that's favorable for emulation. Lots to do yet, but if you want to see the count go way faster, snag this set of files.
The little blob in the corner is a write to the screen for comparing a value. Quick 'n dirty debug.
Edit: I've learned some stuff. One of the biggies is figuring out quick 'n dirty ways to debug. When it's something like this, you don't get much. Probably why people buy or write debuggers. What I ended up doing was writing a value to spin, which can be seen on the screen as a character, or interesting blob, depending on what it is. In the PASM code, write the state of things to the screen at times. That's enough to work through test cases.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/27/2008 10:40:03 PM GMT
After spending some time to understand the code, I'm was wondering why the registers such as PC are being store in the hub rather than the cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I see VCS clone in the near future.. Maybe even an Apple][noparse][[/noparse] clone.. [noparse]:)[/noparse]
Now, If I can just get Steve Jobs to read his email and release the apple2 roms. [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
Jetfire, a full on 6502 is probably gonna take more than one COG, unless somebody some where has some wicked way to fit the instructions into just one, at speed. If this happens, then the regs should be in the COG. It's a nice notch faster that way!
OBC, Apple ][noparse][[/noparse] roms are all over the place. I've snagged an emulator, roms and such already. Wrote a coupla Applesoft basic toys last night. It's still in my brain after all this time! God, that was a slow *** basic. The integer basic was way faster, though spartan. Anyway, some low-res basic games would probably fit in the Propeller RAM. Simulate a 4 or 8 K Apple maybe.
On a somewhat related topic, I love the Apple machines almost as much as I do Atari and C64. (and I lean Atari :P BTW...) The documentation that came with them was excellent, and the machine was just open. Card slots there for the hacking. In fact, a Propeller on a card, in an Apple ][noparse][[/noparse] case would just rock!! Hmmm ... maybe I'm gonna have to E-bay this year and score one. The ROM listing was included, commented too! That taught me and my High School buddies Assembly language back then. We just looked at the ROM listing, hand assembled our own codes, and ran them from the monitor. The little mini assembler in there helped out big, when we found out about the thing. Apples were not the greatest in terms of speed, but in terms of utility, remain unmatched among 8 bitters!
They sold through '93 for a reason!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/28/2008 10:32:44 PM GMT
Never played with an Apple ][noparse][[/noparse] they were never really big over here.
maybe I'll grab an emu and have a play.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
That machine is where it all started for me. Schools had 'em, so that's where the computing and gaming happened. BTW: The Robotron port for Apple is just awesome. Wouldn't expect that, but it is.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I reworked the fetch_opcode part to make it faster, smaller, and maintain hub sync.
fetch_opcode rdlong _PC, PC rdbyte _opcode, _PC shl _opcode, #2 add _opcode, opcode_jmp rdlong _jump_instruction, _opcode add _PC, #1 _jump_instruction nopand change tjnz _instructions, #fetch_opcode to:
I've started reading up on the 6502 instruction set and architecture.
Thanks for that. I'll plop it in there on the next pass. There's a bug in BNE too. Works for backward branches, but won't work for forward ones. Typed in TEMP, when it should be _ALU. That one is tagged too, just FYI.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
For example, for a9 you would put "mov A, PC" into the jump table command, the "_jump_instruction" is followed by a PC incrementer, it goes into "done" and loops back for the next opcode.
This means that a9, a2, and a0 would go from 12 longs to 0 longs in the cog. I don't think you can make it any better.
This really only makes sense if you can put everything in one cog. If you need more than one, the rest of the opcode handling would be in another cog, the registers would be written out to the hub, then read back in when the second cog finishes.
At the target speed, we have 17 instructions (give or take a few, depending on 80mhz clock vs 96 mhz), per 6502 clock cycle. The one byte instructions are gonna be tight. The longer ones at 7 cycles will be fine. Each HUB fetch equates to roughly 4 instructions, to help compute the cost of things.
That's a really great idea for using the jmp table!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
' $B5 LDA _LDA_ZP_X rdbyte _TEMP, _PC 'get PC add _PC, #1 'update PC rdbyte _X, X 'get X add _TEMP, _X 'add to get address and _TEMP, #%11111111 'keep only 8 bits, wrap around rdbyte _A, _TEMP 'load A from address wrbyte _A, A 'write A jmp #done ' $AD LDA _LDA_ABS rdbyte _TEMP, _PC 'get low address add _PC, #1 rdbyte _TEMP_A, _PC 'get high address shl _TEMP_A, #8 'combine low and high add _TEMP, _TEMP_A rdbyte _A, _TEMP 'load A from address add _PC, #1 'update PC wrbyte _A, A 'write A jmp #done ' $B9 LDA _LDA_ABS_Y rdbyte _Y, Y 'get Y rdbyte _TEMP, _PC 'get low address add _PC, #1 add _TEMP, _Y 'add Y to address rdbyte _TEMP_A, _PC 'get high address shl _TEMP_A, #8 'combine low and high add _TEMP, _TEMP_A rdbyte _A, _TEMP 'load A from address add _PC, #1 'update PC wrbyte _A, A 'write A jmp #done ' $A1 LDA _LDA_IND_X rdbyte _TEMP_A, _PC 'get PC add _PC, #1 'update PC rdbyte _X, X 'get X add _TEMP_A, _X 'add to get address and _TEMP_A, #%11111111 'keep only 8 bits, wrap around rdbyte _TEMP, _TEMP_A 'get low address add _TEMP_A, #1 rdbyte _TEMP_A, _TEMP_A 'get high address shl _TEMP_A, #8 'combine low and high add _TEMP, _TEMP_A rdbyte _A, _TEMP 'load A from address wrbyte _A, A 'write A jmp #done ' $B1 LDA _LDA_IND_Y rdbyte _TEMP_A, _PC 'get PC add _PC, #1 'update PC rdbyte _Y, Y 'get Y add _TEMP_A, _Y 'add to get address rdbyte _TEMP, _TEMP_A 'get low address add _TEMP_A, #1 rdbyte _TEMP_A, _TEMP_A 'get high address shl _TEMP_A, #8 'combine low and high add _TEMP, _TEMP_A rdbyte _A, _TEMP 'load A from address wrbyte _A, A 'write A jmp #doneFrom the current code it looks like the Z flag is being stored in FR. What is the plan for storing flags?
Here's a quick blurb on the flags:
The Processor Status Flags allow your program to control/monitor the various modes of processor operation. Here's a detailed description of their functions.
N
The Negative flag reflects the sign (+ or -) of a value in the Accumulator, X Index or Y Index. N will be affected whenever the MSb (bit 7) * of A, X or Y changes. N will be set (1) ** if the MSb is set and clear (0) if the MSb is clear. N is affected by all these instructions: ADC AND ASL BIT CMP CPX CPY DEC DEX DEY EOR INC INX INY LDA LDX LDY LSR ORA PLA PLP ROL ROR RTI SBC TAX TAY TSX TXA TXS TYA
V
The oVerflow flag indicates a carry from bit 6 to bit 7 of A. It is mostly used in signed arithmetic where bit 7 is the sign flag of a value. V is affected by: ADC BIT CLV PLP RTI SBC
-
- is not really flag but is an unused bit of the Processor Status Register. - is bit 5 of P and is always set (1)
B
The Break flag is used to indicate that a program-generated interrupt has occured. If the source of the interrupt is a BRK instruction then B is set. Any interrupt caused by the 6502 IRQ or NMI inputs automatically clears B. PHP also causes B to be set although I'm not sure why (I welcome remarks from anyone who understands this better!)
D
The Decimal flag is used to enable 6502 Decimal mode arithmetic. Decimal mode is enabled when D is set; binary mode is enabled when D is clear. D is set by SED and cleared by CLD but is also affected by PLP and RTI.
I
The Interrupt Disable flag is used to mask interrupts from the 6502 IRQ input and is ideal for use in interrupt handler routines. It has no effect on program interrupts generated by BRK. Use CLI to allow a program to be interrupted by IRQ and SEI to disallow interrupts from IRQ. I is set by BRK and is also affected by PLP and RTI.
Z
The Zero Flag is set whenever an operation causes a result of 0 (zero) in A, X or Y. Z is affected by all these instructions: ADC AND ASL BIT CMP CPX CPY DEC DEX DEY EOR INC INX INY LDA LDX LDY LSR ORA PLA PLP ROL ROR RTI SBC TAX TAY TSX TXA TYA
C
The Carry flag indicates that the result of a math operation exceeds 8 bits and in this sense it can be thought of as the "ninth" Accumulator bit. C is affected by all these instructions: ADC ASL CLC CMP CPX CPY LSR PLP ROL ROR RTI SBC SEC
Probably should step up and change _FR to _SR to match the 6502 convention. It's really both a place for flags and processor status, like BCD mode.
For a zero operation, we would perform a logical and with the SR and write that back to the hub. Since it's only a byte long, we can use literals in PASM, and constants to setup all the bit operations. (I think!)
CON set_zero = %0000_0010 (need to check if this is bit 2 or bit 7) if_z and _SR, #set_zero wrbyte __SR, SR▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 12/29/2008 8:22:30 PM GMT
You may have guessed I'd pop up here from the Prop section looking for any tricks to speed up the 8080 emulator. Had a quick scan through your posts here unfortunately I know very little about the 6502, programmed one briefly on an SBC back in uni a million years ago, so I don't follow every detail.
Seems you did a Spin version first, as I did for the 8080. The Apple ][noparse][[/noparse] plan seems sound enough. How does your PASM emulator go? Is there a blob of code you could show us?
To be honest I've hit a wall with the 8080. Run out of ideas. It's already on it's third major rewrite!
I think about splitting it over two or more COGS from time to time but without actually putting the time in to code it I can't convince myself it would get much faster, what with the overheads of moving registers into HUB RAM and keeping everyone in sync. Perhaps you have some ideas about that that I have missed.
It is possible that using external RAM would actually speed it up as there would be no need to test for reading from RAM or ROM areas or range checking either of them.
Happy New Year All !
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
want me to have a look at your 8080 emu when I get 5? for optimisation ideas?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
a) It might make it easier to access individual registers as bytes and register pairs as words.
b) It's a doddle to then have some kind of breakpoint system and be able to see the registers from "outside".
It was not so fast and I gave it up but perhaps it's time to revisit the whole idea. Also I took it as a challenge, at the time, to get the whole emulation into a single COG with no LMM. Which is possible but the tricks required make it slow again.
I'd love for you, or anyone, to review my efforts. Attached is the actual emulator file. May be tricky to follow if your not familiar with the 8080.
If you'd like to run the whole CP/M system it's version propaltair_2_1.zip on page 4 of the CP/M for Propeller thread.
Cheers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
and b) is the added bonus [noparse]:)[/noparse]
yes i'll take a look, next year rofl [noparse]:)[/noparse] sounds so far away, yet it's only 3 and a half hours away here lol
Happy New Year everyone btw [noparse]:)[/noparse]
All the best for 2009
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Heater, so far the approach was to hand assemble some relocatable 6502 code. Write a partial 6502 in SPIN, then PASM that. The demo up thread has the partial chip, running over 1Mhz. That's according to a very thumb in the wind benchmark! Basically, the Atari 400, running at 1.7Mhz, with video DMA happening, counts to 9,999,999 in a little over 3 minutes. This one can do it in under 2. One byte instructions are a bit slow, or right on the edge. Multi-byte ones are running good, PASM instruction count wise.
What's there is missing some stuff that's going to be a challenge for speed. I expected slower on the first pass, so it's all favorable at this point.
http://forums.parallax.com/forums/attach.aspx?a=27192
That link is the work in progress.
We kind of stumbled on the Apple, looking for 6502 code to work from. The ROM is a bit big, but aside from that, the machine is just dead simple. There are text / basic lo-res games that run on a small memory too.
Thanks Jetfire, BTW. Work prevented me from doing anything with this. Because of COG space, it's going to be necessary to have code shared among instructions. I wouldn't code too many more just yet, until that gets sorted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 1/1/2009 5:14:14 AM GMT
Sure I did a lot of hand assembling to when I started out.
What ideas do you have for methods to synch up multiple COGs?
I was thinking to have a shared counter in HUB RAM such that:
1. Each cog reads the counter prior to fetching and instruction checking if it has something to do in it's dispatch table.
2. If the dispatch table indicates "nothing for you" the COG sits in a loop waiting for the counter to change.
3. Else there is an op to execute and then increment the counter.
4. Go to 1.
This is nice as there is no "master" COG.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
will resume normal prop fun soon [noparse]:D[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
run Applesoft BASIC on the Prop? There are a TON of programs which the
door opens to here.
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
..drool..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!