candle

i just wonder if it would help if we change reset time constant for 800 - it was nessesary for 400, as newer cpld chips needs much longer to configure since they are rewriting flash content to the ram-based fabric just thinking out lound

and no compatible devices exists i've also run out of ideas on how to debug it - every test we've conducted passes when machine is working outside the bios and the only issue i've found was that "config reset" when booted first time on cold

all i have right now is 2 xe prototypes and 3 xl ones any production runs are postponed till noone knows when since the situation on component maket - there is absolutly lack of any CPLD/FPGA chips that would be usable I was cosidering even a board redesign just to address the issue, but there is nothing i could change current CPLD to (in comparable price range)

that doesn't work i have hard time just compiling darn thing - it either fits or not - as most of resources are exhausted

in original rom image stock os was not that stock - i noticed that speedy audio test way too late

very little and very late update - this was in december 2021... i still have some timing issues between 6502 and SALLY CPU boards

just to help you track this:

this mean that it could not access CF card either - at least we have consisten picture here back to the manufacturer it goes, unless you can test it with another 800

IC looks fine, so next logical test would be to issue some ATA commands with memory monitor and see what is in the registers perhaps Jon has some test suites for this from early stages you could also see if my original loader works (you can run it from sio) fat32-incognito.xex

please check U3 (on the bottom side of the board) for missaligment & short circuits on its pins

https://www.pcbway.com/project/shareproject/VBXE_Atari_800_carrier_board.html

yes, gbs buffers whole frame, thus the lag, tearing and ability to work with any input source vertical frequency whereas vbxe and vbxe alike devices just buffer enough to display same line multiple times to get the job done, these need only a single line delay but have their flaws aka decreased compatibility this is all fine if you're driving TFT or LED panel directly, as signal range it can accept is quite wide, but not so much when it comes to consumer-grade monitor, that has preprogrammed few dozens of input signal resolutions and it searches through the table to find closest match

i've made some document on how to connect to vga,

It seems it's not clear to the public on how to use VBXE with VGA monitors, so i've made something to cover this hope this helps somebody. As mentioned in the document, VGA for PAL systems is hit and miss, especially with LCD monitor since most of them don't know how to handle 31khz HSYNC with 50HZ VSYNC signals - CRT should don't care and display it flowlessly, but i guess it's not the point. For NTSC regions this might be a perfect choice since there is no real RGB capable LCD monitors out there, and NTSC VBXE VGA generated signal is up to the specs for these and should pose no problems. happy hacking. Please read carefully whats in the documentation about RDY/CSYNC pin, and if you're unsure, or can't really solder - let someone else who can do it. FPGA chips are not that fragile, but still, they don't grow on trees and replacing one if damaged won't be plesant thing to do. vbxe2-vga.pdf

it will also flag anything containing "executables"