Open mwedmark opened 2 years ago
YnotZer0
commented
1 year ago I have a couple of these - they are awesome, but not sure that the way the VGA output works is compatible?
https://shop.pimoroni.com/products/pimoroni-pico-vga-demo-base?variant=32369520672851
pi-gram
commented
1 year ago In fact, I've just now got the SDCard working with this pico demo board via this code-base - I'm just working out how to get the VGA to work too. currently got a pixelated red or green mess. Am sure it's just a lit bit more configuration as it is RRRRR-GGGGGBBBBB where the - is a pin used for the sdcard.
I've trimmed the emulator down to the basics and just executes a single emulation of the atari800. It's been interesting figuring out how this code works. The one thing I will say is that is 100% needs a keyboard as it does an infinite loop detecting keypresses and won't do anything/show anything until a key is pressed, obv. I've bypassed this in my testing/hacking about code. Now, if I can figure out how to use the 3 buttons on the board so I don't need a full keyboard, that would be something and I could use the 3 buttons in a limited way(left/right+fire). Give me a few weeks and I'll see what I come up with.
mwedmark
commented
1 year ago Great work! Would be cool to be able to check out some emulation on the Pico. If possible, I can also "chip in" (no pun intended) with testing or some part of the implementation.
pi-gram
commented
1 year ago well....I made some progress: first update - in a very raw but working state As I say in the readme, I have it functionally working. I specifically focused on an atari800 emulator, so I could drilldown and figure stuff out. I had issues with the dual-screen, VGA and TFT configuration, so I mostly ripped that out as I was only interested in the VGA and I've hardcoded a few things to spoof the code into working, such as a button press value.
Under the screenshots folder you can see a couple of images and a short video of the PICO demo board booting up. The VGA colours are messed up and currently no buttons, so don't expect anything useful atm.
In the CMakeLists.txt file, if you comment out the a800 source and uncomment the testvga line and rebuild you can then just see the testvga code running - this proves the SDCard and VGA code works and is a good base to start headscratching to figure out how to get the colours aligned - I may get a chance to look at this later in the week, we'll see.
If you can figure out how to get the RGB setup correctly that would be awesome! I just haven't followed throught he steps to figure it out. I was going to do a trace and compare of this code: Breakout vga version ...that's also where I'm going to "borrow" the button press code from for the pico demo vga board. Again, later / next week.
For now, I'm pretty happy that I've figured out (in a pretty short time) how the MCUME code ties together, how to graft new SDCard (PIO access) in so that works and re-map the VGA to work from the pico demo board. Feel free to clone and play around and try and figure out what is going on etc..etc... as I say, before the _Step() call is looped through I have quite indepth debug output that helps with tracing the code through the files. you'll see.
UPDATE: I've switched over to the picovga library in the checked in repo. code - I now have a little bit of BLUE and it's mostly all GREEN now. I noticed RGB16() params were using 11/5/0 values, that looked logical to me to indicate usage of the 15RGB pins, but the VGA() settings were still using the old BBGGGRRR(8-bit) settings, so I change them to match, also changed the R16,G16,B16 values. anyway, this is where I 100% confess, I have absolutely no clue what I am doing in relation to these values! If anyone has any ideas / guidance it would be really appreciated. I feel it is close....
Jean-MarcHarvengt
commented
1 year ago indeed, the 8 bit VGA driver included in the project was derived from the orginal 16 bits driver. Reason why I did that was to have a smaller 320x240 frame buffer that could store in the RAM of the pico. (64k iso 128K). Now may be you can fit a 16bit buffer for the Atari 800. Most of the computer emulated have a color fixed palette (as the C64, spectrum, ...). I think the Atari 800 is the exception as you can create raster colors without a palette (a bit like on the ST 4R/4B/4G color definition , I am not too familiar with Atari 8bits) you could keep the 8bit buffer and change the code of the driver to only use 332 remapped on the 16lines on the highest bits of the 565. So fit 3 bits of R on the highest 3 bits of the 5, 3 bits of G on the highest 3 bits or the 6, and 2 bits of the B on the 2 highest bits of the 5. making Lowest bits being 0
pi-gram
commented
1 year ago "you could keep the 8bit buffer and change the code of the driver to only use 332 remapped on the 16lines on the highest bits of the 565. So fit 3 bits of R on the highest 3 bits of the 5, 3 bits of G on the highest 3 bits or the 6, 2 bits of B on the highest 2 bits of the 5. making Lowest bits being 0"
If I'm following along correctly, then within the VGA_t4.h file, where the VGA_RGB() sets these values:
and that is where I need to translate what you said (up there^^^) into those settings. Again, I have no idea what the original is actually doing, let's play a game of guess-work to replace numbers that I "think" are correct and see what happens.... I attempted to translate and I tried:
But that is clearly not correct! I just get a few more shades of GREEN.
I also noticed that the same VGA_RGB() setting is also made within include.h, so not sure which one is the correct one to change - am currently just changing both.
As a side-note of investigation: I have figured out that the emulator itself is actually setting the palette within: at8_Init() emu_SetPaletteEntry(R32(colourtable[i]), G32(colourtable[i]), B32(colourtable[i]), i); where the R32/G32/B32 values are derived from: emuapi.h
and that emu_SetPaletteEntry() is setting the palette from the values read within colours.h:
if (index<PALETTE_SIZE) {
palette8[index] = RGBVAL8(r,g,b);
palette16[index] = RGBVAL16(r,g,b);
}
where RGBVAL8/16 values are derived from: vga_t_dma.h
which loops back to the VGA_RGB define settings from the VGA_t4.h file. That was a slightly long-winded walk-through of how I believe the VGA_t4.h setting then affects all of the other setting values.
Jean-MarcHarvengt
commented
1 year ago Sorry, this is not what I meant. I really meant change the VGA driver to output the 8 bit RGB to only 8 lines of the 16 you use (need to change some mapping I guess in the driver?) You could also rewire it (may be by creating an in between socket) between the pico and the PCB you use , that only pick up 8 lines as I was outputting it and wire them to the highest bits of the RGB lines
This board is pretty close to the description shown by rp2040/pico reference documentation about a reference board (also called vga_board). It includes:
Would be great if this super package had support for this board.