Hmm, seperating the Timing and Address calculation does decrease the total clock-to-output latency, and when i change the synthesiser to optimize for space instead of speed, the total circuit size goes down from 113 Macrocells to 73.
and ironically it didn't even decrease the maximum operating frequency, it's actually higher than the old circuit at 76MHz (instead of 33MHz). which ultimately doesn't matter as long as it's >25MHz, but i still think it's funny.

so thanks for the idea, i think i'll stick with it!
but even though i have enough room for a small 32-Byte ROM, i still need the read only status registers for the FIFO's Flags, and since i already handle those in the second CPLD (the ATF1504), moving the ROM from it to the 1508 wouldn't reduce the total amount of ICs required and i would also have to downgrade to a 32-byte ROM instead of the 128-Byte one that fits into the 1504.
so i'll still keep the ROM seperate. but atleast now i have more space in the 1508 for future expansion!

Small update, i now own a Solder Iron so i can do work anytime without having to take it to work. very useful!

the PCBs for the Video Card arrived and after assembling and botch wiring, i hooked it up to the SBC.
now the FIFO ICs didn't arrive yet so i cannot test all of the card, but i can see if it's displaying anything at all and if the onboard CPU is working (changed the Video ROM to have the CPU fill the upper 32k with a pattern)

and while i do get a video output, the onboard CPU isn't executing any code (well the SYNC pin is doing stuff but nothing useful). even after relaxing the timings on the BE and CLK pin (ie it pulls the clock high and BE low one cycle before the Video Card is accessing RAM to make sure the CPU has enough time to pull itself off the bus) and it still doesn't work.
checking the VP Pin it's being pulled low at ~2.5MHz aka every 10 clock cycles.
honestly i cannot do a lot of debugging without a way to look at a lot of signals at the same time, so i'm thinking of getting myself the LA2016 Logic Analyzer. 200MHz with all 16 channels active should be fast enough for this. and at 160 EUR it's not that expensive.
so once i got it and figured out how it works i'll make another update.

also yes i did also tr to run the CPU at 12.5MHz without having the video circuit pull BE or the Clock at all and it also didn't execute code...

anyways just thought i'd share what has happend so far maybe someone else has an idea about what could be wrong.

alright now i do have a Logic Analyzer but the probes are garbage, especially for PLCC ICs.
anyways after some... mangling or cheap probes i did get a readout of the data bus and some control signals.

the PHI2 and BE pin behave like i would expect, PHI2 goes high followed by BE going low, and at the end BE first goes high before PHI2 resumes normal operation.
but despite that the CPU is still stuck in a reset loop... atleast sometimes.
at random when i power cycle the system the VPB pin stays high but it doesn't appear to be running the test program from the ROM...
in addition the R/W pin seems to remain low while BE is pulled low... which makes no sense to me, isn't R/W supposed to go tristate? i have a pull up resistor on it as well...

also sometimes R/W just always stays high alongsideVPB being high...

also the program i'm using from Kingst is lacking the ability to combine multiple channels so you can read them as a single multi-bit wide value so i cannot confirm exactly what is on the databus, but i can tell when VPB is pulled low that the same data is always present on the bus, which should be from the ROM.


even without the ability to combine channels i can tell that the data on the bus is looping everytime it pulls VPB low again.

any ideas what could be going wrong? i really don't think it's the speed as my old SBC ran fine at 24MHz using a larger PCB and DIP Packages. but i could still try 12.5MHz again or maybe just disable the video reading/BE stuff to see if maybe then it stays stable...

"Sometimes" ... the bane of all automotive drivability techs!

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I can't answer that, but I can offer a suggestion.

To me it seem almost impossible to make conclusions about the overall "big picture," so I suggest you roll up your sleeves and zoom in to give some meticulous attention to detail. Start at the beginning. What happens just after reset? Can you see the reset vector being fetched? If so, what happens next? When the first instruction executes, is it the one you expected? What about the next half-dozen instructions that follow?

This kind of work is tedious, but don't be tempted to overlook any anomalies you encounter. The '816 is "only following orders," and you job is to figure out how your intended orders differ from what you actually asked it to do. Hope this helps!

BTW, the logic analyzer isn't strictly necessary, and in some case will be more fuss than it's worth (IMO). In simple cases (such as the reset sequence) one can do just as well, or better, by disconnecting the oscillator and supplying a clock that's derived from a debounced pushbutton.

-- Jeff

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

well my dumb graphics card arrived.
it's "dumb" because it has no CPU on it, just a CPLD hooked up to 4 Dual Port SRAM chips for a total of 32kB of VRAM. (atleast until i got some 16k chips for a total of 64kB of VRAM)
it outputs 640x400 in monochrome and it almost worked first try.

i had some issues where the CPU would execute code from the ROM fine but was never able to return from subroutines... so something seemed wrong with the RAM.
i made a small program that would just load the ASCII character "A" into the Accumulator, push it to the stack, wait a bit, then pull it again and print it to the Terminal.
the entire terminal was filled with: @@@@A@@@@@@@AA@@@, so somehow bit 0 was getting screwed up when accessing RAM.
changing the system clock from 20MHz to 12.5MHz fixed the issue, but also means i lost 37.5% of my performance...

so overall i assume that the 20MHz clock was so close to the system's limit that the extra traces up to the VRAM Chips was just too much. maybe a 74x245 inbetween could've helped to avoid some noise when not accessing VRAM, and since VRAM always gets a wait cycle anyways i wouldn't need to worry about the extra latency either.
hmm, maybe an idea for version 2 (or any future SBC i make with Expansion Connectors).

anyways, after all that mess i finally hooked up a screen to the VGA Port and it actually outputs an image!
i then made a program to write some values to VRAM. clearing all of VRAM worked perfectly, but writing all 1s gave me this:

now this shape is confusing because if it was just one of the RAM chips having a dead bit (bit 3 to be specific), then i'd expect the atrifact to start somewhere on the screen and wrap around a bunch of times. but this just starts like 1/4th across the screen and then just disappears again in the last 1/4th, except for the last few lines where it's just always present.
and i know for a fact that the Video circuit just walks linear through memory, one chip at a time... so this makes no sense to me right now.

i will try to swap around some RAM Chips tomorrow (or rather today because it's 4 in the morning and i need to go to bed), i'm kinda just hoping that fixes it but i'm overall too tired right now to think properly

just thought i'd share this update for now.

alright i got a bit further. after some botch wires to connect the CPU's A13 to the CPLD (because the card was originally designed to only take the 16k DP-RAM chips, so with the 8k ones it would still take up a whole bank but every 8k chunk was mirrored once).
i also had to botch the clock, moving it from GLCK3 to GLCK1, because the MAX7000S doesn't actually have 3 global clock pins! it only has 2 and i didn't know that so the VGA clock was coming from a regular pin, which is why Quartus II's time analyzer was yelling timing issues at me.

from reprogramming the CPLD multiple times i also found out that the missing bit on the screen moves around everytime i program the CPLD, meaning it has something to do with the internal logic and that the VRAM is completely fine and functional (even verified that with a small Program to write and then read and compre the values from VRAM)
right now bit 1 is always missing across the whole screen.

i'll probably have to learn to use Quartus' Simulator to see exactly what is happening, if it's maybe optimizing away one of the bits, or one of the physical macrocells on the chip is damaged so everytime i synthesize the Verilog, it moves the macrocells around and another bit ends up dead.

EDIT: ok the CPLD itself is fine i tried the same program on another one and it had the same exact dead bit on screen

Finally some good news, i got the video to work.
Monochrome 640x400 without any stripes! (though there are still those black stripes in the background but i think those are just caused by my suboptimal DAC, plus in person they're barely visible)

one thing i learned while debugging this is that ATMISP only loads the program file from Disk once the first time you load the .chn file and program a device with it.
anytime afterwards it uses some local copy of the file it kept in Memory.

i found this out when trying out various ways to solve ths tripping issue, i always kept ATMISP open, so everytime i re-synthesised the logic in Quartus, and used POF2JED on it, it made no difference because ATMISP wasn't using the updated file, it was using the local copy of the old one...
so i just had to re-select the file in the "Device Chain Hierarchy" tab everytime i updated it so ATMISP would actually read it.

oh well lesson learned for the future i guess!