the code is really basic.


the Accumulator is always 8-bit when entering the ISR since the test code only sets it to 16-bit once to define the Direct Page, and then sets it back to 8-bit before entering an infinite loop.
I'm pretty sure the crash happen on the RTI since that's the only instruction that effects the PC.

hmm i thought about it a bit more and i don't think the crash is because of the speed alone since it's clearly able to write the Interrupt return address to the stack without crashing (which happens at 25MHz). so it might very well be the decoding logic's latency.

i'll have to somehow attach multiple Scope probes to things and see what is happening. maybe a test program that just constantly writes and reads to/from memory so it doesn't crash and i get more than enough chances to catch the signals

How do you know it can write the interrupt return address to the stack? It doesn't return from the interrupt, so there's no guarantee the address was stored correctly.

What would be useful here is a test program which exercises the CPU and RAM, doing lots of RAM accesses throughout the RAM (so using the bank address capture) and, ideally, using all CPU instructions, but which doesn't use either I/O or ROM. Is there a version of Klaus Dornan's test suite available for the '816? If so, maybe that could be integrated in. If you have such a program and can leave it running for a long period of time at 25MHz without any failures, that shows that the basic CPU/RAM system works at that speed. Any problems then are likely to be issues with the CPLD programming or access time issues with ROM or I/O.

Are you using the fastest version of CPLD? (7ns propagation delay I believe).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I agree with your appraisal that "something must be going wrong." And it may be, as you say, that the decoding logic takes too long... but it also may be that the wait states are not occurring as planned. It would be a really good idea to check.

This kind of approach is one way you could verify the wait states for ROM and IO. Alternatively, you could disconnect the oscillator and instead just single-step through some test code.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

alright, while trying to figure out what was happening i seem to have broken more stuff...
i just added a lot of single letter "print statements" throughout my code and there are 2 very close to eachother. one directly after switching into native mode when coming from a reset, and another after the long jump to bank 1 where the actual test code sits.
the first letter prints, but the second doesn't. conclusion: i fricked up the banking logic somehow. comparing the logic simulator and Quartus' RTL viewer the banking circuit looks perfectly fine so i don't know see why it would be failing.

also for testing purposes i'm using my 1.8MHz Oscillator, just to exclude "tight timings" as a potential reason for things not working... i don't know if i can just use a push button as a manual clock, i can use one of my spare DS1813's on a breadboard as a debounce circuit.

either way, i'm tired of debugging this so i'll continue tomorrow.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Are your single-char print statements a lda# & sta SERIAL like in the NMI routine?
Is SERIAL a device (like a UART) that can overflow & lose characters if you write to it too fast without handshaking?

hmm, i don't have an 74AC14 lying around, just normal hex inverts...
but i do have some 74HC123's that could be used instead.
alternatively i could also just use one of my Arduinos to generate a button controlled clock signal... actually i could connect the entire data and address bus to the Arduino as well and just log what it's doing, like a poor man's logic analyzer (i used to do that with my first Z80 Breadboard computer).


Technically it can overflow since i'm not checking for the "FIFO has space" status flag, but with a 512 Byte sending buffer and a baud rate of 115200 (up to 921600) it would take a lot more than a few characters from a ~900kHz CPU to do it.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

ok so i used my Arduino Mega as a Logic Analyzer, basically it would wait for something from USB, then prints the current state of the RWB pin, Address Bus, and Data bus.
afterwards it would monitor the PHI2 pin of the CPU, and advance the clock until PHI2 goes low and then high again.
that way the program would only print the current state exactly once per bus cycle, regardless of wait states and such.

and acording to the DIY Logic Analyzer... everything works perfectly fine. i can see the CPU reading the Reset Vector, starting at $00FF00, going into native mode, and then jumping to $010000.
so i removed the Arduino's wires and just inserted the 1.8MHz Clock again and it still works fine. i even tried the 40MHz Clock (20MHz CPU speed) and it also works fine.

hmm, either way i wrote a small RAM test program that goes from $020000 to $02FFFF, writes a byte, does a few NOPs, reads it again and then prints either a "." if the value was the same, or an "x" if not. it would also count the total amount of incoreect values and print them in HEX after the program was over. (i tried it at both 1.8 and 40MHz for a few times the total amount of wrong values was always 0 and i never saw any x's in the terminal)
and since the HEX printing function is an actual function entered via JSL and returns with RTL, and it works fine too, it overall confirms to me that RAM is working as it should.

and whatever the issue was, was likely with the logic and i apparently fixed it and then forgot about (because i was procrastinating the whole project a bit)
the only thing i remember changing was swapping the ATF1508 with another one, because i somehow bricked the first as i wasn't able to program it via JTAG anymore, despite me making sure that JTAG is always set to "ON" when using POF2JED. idk, maybe i missed it that one time and it for some reason disabled JTAG, or the CPLD was actually just faulty and about to die anyways (they do get kinda warm over time, maybe a heat sink could extend their life a bit?).

either way, this means the next step is making a Serial Bootloader! so i can finally write programs without having to constantly remove, program, and reinsert the ROM over and over again.
specifically i want to implement the PGZ format from the C256 described here: https://wiki.c256foenix.com/index.php?t ... inary_file
as that's a format that Calypsi C supports and it's simple enough to handle.
as a later project i also want to create my own PGY format for Position Independent Code (or PIC) as that is one of the things i want to experiment with, another thing being multitasking which works nicely with PIC (i'll probably make a new thread about that over the Programming Section). and then maybe see if i can get the Calypsi C dev to add support for PIC to the C compiler and then make it use the PGY format.

Can I ask about one particular detail? In this previous post you said, "when i run the system at 25MHz (ie 50MHz Oscillator) it crashes [...] also tried it with 20MHz (ie 40MHz Oscillator) and it works perfectly fine"

That made me wonder if maybe the wait states aren't occurring as expected. Before concluding that you apparently fixed it and then forgot about it, shouldn't you run another test at at 25MHz (ie 50MHz Oscillator)? Also, based on your Arduino/"Logic Analyzer" tests, are you able to determine whether the states are occurring as expected?

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

before i had the Arduino wait for the next PHI2 before printing out the current state of the Bus, i had it simply do 2 clock cycles and then print the Bus states. so while accessing ROM or IO it would print the same values twice because of the extra wait cycle. but while accessing RAM it would only print it once.
so the wait state generation seems correct.

And i did try it again with the 50MHz Oscillator and it still didn't work, it either didn't do anything or just printed garbage characters to the Terminal instead of "." or "x" like it should.
I can probably debug it more to narrow down what exactly is causing the issue, but i'm happy that it works at all so i'm gonna focus on the software side for a while.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

that is not really possible in Quartus (or atleast the way i have it setup), i manually assigned all the User IO pins (all 64 of them).
and even if there was an additional pin that i added for tested and forgot to remove, Quartus cannot auto-assign anything to JTAG reserved pins and in this case it would've throw an error as it won't been able to fit the 4 JTAG pins plus >64 user pins on the 68 IO pin device.

so the only possible things that could've "bricked" it are me screwing up something in POF2JED or the Chip itself being faulty.