BRK won't stop it. If you want to stop it and the assembler doesn't have STP, make it a macro that assembles the STP op code. (I'm not familiar with the Kowalski assembler, but hopefully it has macro capability.) It might be something like:

very simple since there's not even an operand. Define it before the first use of it, and it will be the same as if the assembler had it. STP really is a total stop though, not a transfer to some kind of service routine or whatever.

I was about to respond with the macro solution.

Also, note that the only thing that takes the CPU out of suspension is a hard reset.

If you're simply waiting for an external event to occur, WAI is better (watch that RDY line though!). The CPU will wake up where it left off upon the next interrupt (after running the interrupt handlers of course).

To be clear, $DB is the actual STP opcode. The macro simply adds this byte to the program.

Yes, that's what can result. The origin of the problem is prior to that, at the instant that the properly-operating software goes off the rails.

For example, if your jump-to-self loop is at $8000, then the actual bytes of code are $4C $00 and $80. These (like the entire program) all have to be read and interpreted 100% accurately, every single time -- there's simply no tolerance for the slightest error. You can appreciate that anything other than $4C will do something other than JMP -- that's obvious. Or, if the $4C is ok but the $00 or $80 fails to register properly in the cpu, then the JMP will occur but to the incorrectly registered address (which may contain data, inappropriate code or who-knows-what). Once a slipup has occured, the game is lost. But the cpu will blunder onward at full speed. All it sees is a bunch of numbers, be they clever code or total garbage.

Every cycle is an opportunity for error, so there are millions of chances per second. The whole thing is like a house of cards -- any boo-boo will cause it to collapse utterly. It's amazing that computers can be made to work at all -- it really is!

-- Jeff

Heh, made my first macro! Kowalski's assembler is very similar to your TASS? Garth for macro syntax, at least one that simple... I disassembled and saw the $DB at the end.

I have the display initializing very reliably now @2.5MHz straight from the EEPROM, no SRAM.
I am running into something I don't understand: I'm trying to run the software copy routine before the display initialization (to get a feel for how long the copy portion will take), it never makes it to the display init. I know there is no ram to read or write from, but shouldn't it be reading random data, and not getting stuck? I thought it may be some issue with the addresses, so instead of $C000-$FFFF, I tried $4000-$7FFF.

I think I am real close to figuring this out. Thanks!

EDIT: Doh, forgot indirect indexed needs zero page!

I'm at the point now where I might try experimenting with a 512bx8 synchronous ram internal on the FPGA, for zeropage and stack. I think I have enough pins left.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Your copy routine from page 10 of this thread:INC $01 is meaningless when no ram exists. "loop if not there yet" can't be expected to exit at the correct time. The LDA ($00),Y and STA ($00),Y will not function either.

Yup, too anxious! Not as close as I thought. Back to the drawing board...


That routine is very similar to the one I am using. What is the ballpark figure for that routine to be completed @2.5MHz? I figured about 256x(6+6+2+4)+64x(5+3+3+4)=5568 cycles (worst case). (5568x.000000400s=2ms.

Is this right? sounds too fast based on what I've seen before.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

BTW, with the 65816 it is much easier copying data:



No RAM needed, and copies up to 64k from any bank to any other (not sure about bank crossings though.

André

You might as well use MVP or MVN, then it's a little shorter and only 7 clocks per byte. It's interruptible too. Otherwise, you can start at the high end with X at FFF and use DEX, and omit the CPX before the branch.

No, I will not give into the '816! I don't like the MUX'd upper address lines especially! They should have made more pins available.

I will continue to struggle with my 6502!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Then you could ignore them and do your own banking like you are on the '02, but still take advantage of the 816's other added capabilities. It's a more-powerful processor, and, to me, easier to program, even if you don't latch, decode, or use the upper 8 address bits. Somewhere I have a 68000 in a wide (.8"?) DIP which I think has 64 pins though, and I think I've seen 48-pin DIPs as well. WDC could have put the '816 in a 48-pinner to avoid the need for the external '573 latch (which really is quite simple anyway).

The HD63B03 Microcontroller err "Single chip computer" as they call them. Came in a similar configuration. I got one, which is based on the 68** series of microprocessors. No idea if it works, since I got it from someone and its a CMOS part, and I doubt it saw a static wrist strap.

Dimitri

68xx is way ahead of 65xx. No use posting that info here, not on this thread....

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I was referring to Garth's post about the package available in a "special" 64-pin.

Dimitri

I was responding to your "lack of a wrist/(ground) strap" comment.... Where is that IC available?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Not too sure to be honest EE, I was given it. My wrist strap comment is that I was given it without a anti-static bag, while we were both outside. So I doubt it works anymore.

Dimitri