SPI Ram Video Mode

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI Ram Video Mode

Post by Jubatian » Thu Sep 07, 2017 7:14 pm

D3thAdd3r wrote:
Thu Sep 07, 2017 4:55 pm
Quite nice, and 16bit vram could allow a lot more flexibility in tilesets which might help save flash. I guess if sprite blitting is not too effected, that is the ultimate.

Do you think it is possible to squeeze code in the HSYNC with the existing channels, something to give user access to vram? Or perhaps it is best to build into the scanline giving up some width but keeping max sound/UART options? Even if it was nothing more than a circular buffer where it sent 1 raw user byte to SPI per line, it seems it can work. All time requirements are easily met with a scanline in between each one at least. Perhaps even the old UserHsyncCallback() idea could allow the choice of different short asm routines to fit the requirements of the game, and allow a lot of customization without being a different video mode or submode.
You will have no time in HSync to do extra VRAM accesses unless you drop the inline mixer. The mode however could be compatible with music streaming from SPI RAM as for reading the VRAM, it needs to send an address (so each scanline is a complete SPI transaction, in the spare HSync time, you can access something else, but to send an address and do anything meaningful, that's already 100 cycles).

User HSync callbacks (of course assembly only) could be introduced, but they will be a bit tight. Almost every video mode have the inline mixer, usually above 200 clocks for it. With 4 channels (167 clocks), usually there should be enough time to do something of use. I will possibly do inline mixer optimizations later to trim this down (like I did in FoaD). It has no great uses though on the Uzebox as for example in Mode 3, you really can't do anything with video (the VRAM has RAM tiles on it, you can't move around sprites since they are blitted, there is no palette to mess around with). Mode 74 has most conceivable possibilities supported through RAM arrays (such as replacing colors in the palette, generating the sky in Flight of a Dragon).

What would you like to do by the way?

(Scrolling and similar stuff shouldn't be required as the SPI RAM should be large enough to hold a scene, otherwise loading stuff from SD or depacking from SPI RAM to SPI RAM VRAM would be something possibly too complex to be anything useful within HSync)

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r » Fri Sep 08, 2017 10:45 am

Jubatian wrote:You will have no time in HSync to do extra VRAM accesses unless you drop the inline mixer. The mode however could be compatible with music streaming from SPI RAM as for reading the VRAM, it needs to send an address (so each scanline is a complete SPI transaction, in the spare HSync time, you can access something else, but to send an address and do anything meaningful, that's already 100 cycles).
I am not totally hopeless yet that it could fit in with HSYNC with some sacrifice. It looks like Cunning had a faster version of the inline mixer which never got implemented..something probably worth doing now anyway.

I would sacrifice noise(27 cycles) over channel 5/UART(maybe ~55) for most things, but that negates most of the speed improvements in Cunning's version which were to the LFSR. Right now I think I have something that does the right thing at 30 cycles but I have to test and see. It needs to interleave between the channel code for the outs, which will not be the cleanest. It seems it is definitely possible if willing to give up channel 5 as most of the cycles are waiting, which can be interleaved, but I probably overlooked something in the process.

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI Ram Video Mode

Post by Jubatian » Fri Sep 08, 2017 5:33 pm

I overlooked something which will need work if we want to get anywhere near this (an SPI RAM video mode combined with SPI RAM music).

The problem is that music plays during VBlank, so you have SPI accesses normally fired from interrupts. You wouldn't be able to do anything with the SPI RAM based video mode because of this from the main code. The solution would be either using the VSync mixer (lots of RAM), or developing a mixed mixer, which runs as an inline mixer during the video frame, but at the end of the frame, turns into a VSync mixer to precalculate a buffer which can cover the VBlank. So this way no VBlank SPI would occur. It wouldn't be slow either as during VBlank then the HSync interrupts would be shorter (the audio plays from the buffer).

EDIT: I know about CunningFellow's mixer, and I did some further work on it for Flight of the Dragon (Foad's mixer is so fast that I could get it to play five volume-interpolated wave channels, three serve the music, two the effects. Maybe that would make for 7 normal channels, I can't recall now, but adding volume-interpolating had a nice result, and I didn't want to give it more RAM anyway).

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r » Sat Sep 09, 2017 6:15 pm

Perhaps the cost of doing it in HSync is not worth it, as it comes at the cost of sound and might be more complex and take more code space. I guess it is less a sacrifice for games that need it, to run a shorter screen or just less scanlines so that in the worst case scenarios, there is enough cycles to get things done in VBlank....I think this is what you were originally saying. It at least seems easier in some senses, though running out of cycles could have more issues than a normal video mode.

Something like 80 sequential horizontal tiles per line of VBlank or ~15 vertical tiles is probably good performance for most stuff only changing a few tiles per frame max.

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r » Mon Oct 30, 2017 5:48 am

I am very tempted by this to throw some development time at this now. As far as streaming music, it seems even the buffering code could be internal to the kernel and not require user code intervention. Otherwise with a vsync callback I think it is fine. The buffering code is fast to load just a few bytes before user code then release the SPI ram. The drawing stuff would just assume it needs to start and end any transactions each frame. Then I think it is even safe enough for a user program to directly write vram (first thing) per frame. The caveat is the same one that is always there, perhaps just more extreme:take too long, expect undesired behavior or crash.

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r » Wed Nov 01, 2017 12:05 am

A little off topic to the original tile-like vram, I was curious about what a GUI would look like on Uzebox. Something totally black or white like the Macintosh SE had. Alec demonstrated the 360x240 4 cycle mode right away when the SPI Ram subject came up, though I don't believe there was ever source code posted for it. I had to think on this a bit how that was even possible. I am trying to figure out if a 3.5 or even 2.5 cycle version is possible. So far this is the best I can figure:

Code: Select all

ldi r16,255;for movw restore
ldi r17,255;for movw restore
ldi r20,255;white
ldi r21,255;white
ldi r22,255;white
ldi r23,255;white
ldi r24,255;for next SPI byte

.rept (420/8)-1

;output pixels
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;pixel 1, 4 cycles
in r19,SRDR;read current 8 pixels from SPI Ram
sbrs r19,7;is pixel white?
clr r20;load black if not
out _SFR_IO_ADDR(DATA_PORT),r20
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;pixel 2, 3 cycles

sbrs r19,6
clr r21
out _SFR_IO_ADDR(DATA_PORT),r21
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;pixel 3, 4 cycles
out SR_DR,r24;queue up next byte from SPI Ram
sbrs r19,5
clr r22
out _SFR_IO_ADDR(DATA_PORT),r22
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;pixel 4, 3 cycles

sbrs r19,4
clr r23
out _SFR_IO_ADDR(DATA_PORT),r23
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;pixel 5, 4 cycles
movw r21:r20,r17:r16;restore r20 and r21 to white(possibly cleared previously)
sbrs r19,3
clr r20
out _SFR_IO_ADDR(DATA_PORT),r20
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;pixel 6, 3 cycles

sbrs r19,2
clr r21
out _SFR_IO_ADDR(DATA_PORT),r21
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;pixel 7, 4 cycles
movw r21:r20,r17:r16;restore r20 and r21 to white(possibly cleared previously)
sbrs r19,1
clr r20
out _SFR_IO_ADDR(DATA_PORT),r20
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;pixel 8, 3 cycles

sbrs r19,0
clr r21
out _SFR_IO_ADDR(DATA_PORT),r21

.endr
...last iteration needs to save 2 cycles to avoid going to 1442
I do not have a good framework or experience for quick setup, as making video modes is still quite new to me so I have not tested it. It seems like that almost works to me at least in my head, for a resolution of..almost(1442 cycles) 412x240 at 3.5 cycles per pixel(though probably 412x200 or less if you want time to really draw stuff). Problem is I don't restore all the registers for next iteration so it wont exactly work, does anyone see some optimization how I could get those registers back to white in time?

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI Ram Video Mode

Post by Jubatian » Wed Nov 01, 2017 7:47 am

D3thAdd3r wrote:
Wed Nov 01, 2017 12:05 am
A little off topic to the original tile-like vram, I was curious about what a GUI would look like on Uzebox. Something totally black or white like the Macintosh SE had. Alec demonstrated the 360x240 4 cycle mode right away when the SPI Ram subject came up, though I don't believe there was ever source code posted for it. I had to think on this a bit how that was even possible. I am trying to figure out if a 3.5 or even 2.5 cycle version is possible. So far this is the best I can figure: (...)
My experimental Mode 748 already has this mode at 3.5 cycles / pixel: here. I will redesign the mode somewhat though as I already have an SPI RAM VRAM scanline loop for the in-game part with 2 byte VRAM indices. Will come later though as now my highest priority task is finishing Flight of a Dragon, eh, I should really have one game completed after so long! :) (The source for that mode is available on GitHub)

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r » Fri Nov 03, 2017 4:24 am

Now I remember that one, it is quite nice. I suppose that would be about the ultimate then, if nothing could be gained by dropping attributes for black and white only. I guess at the moment I should focus on other projects besides dreaming up operating systems and other stuff I will never have time to do.

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: SPI Ram Video Mode

Post by Jubatian » Fri Nov 03, 2017 6:10 am

D3thAdd3r wrote:
Fri Nov 03, 2017 4:24 am
Now I remember that one, it is quite nice. I suppose that would be about the ultimate then, if nothing could be gained by dropping attributes for black and white only. I guess at the moment I should focus on other projects besides dreaming up operating systems and other stuff I will never have time to do.
Attributes are optional in it. Line 431 loads the selector flag into 'T', then for example at Line 533 you can see an attribute mode selection within the scanline. When using attributes, the mode takes 96 bytes for a tile row, otherwise no RAM is taken. RAM consumption in attribute mode is the same as the 7cy/pixel 4bpp mode's, so the two modes can be freely mixed, ideal for story screens or graphic + text adventures. Maybe 3cy / pixel is possible without it, but I didn't go that way since the normal Mode74 graphics is 7 cycles / pixel (so I had to align with those pixels).

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: SPI Ram Video Mode

Post by D3thAdd3r » Fri Nov 03, 2017 6:45 pm

Mainly my interest in no attributes has only to do with the GUI for an OS like I said. That is purely because I acquired that Mac SE which is useless for me, but reeks of retro awesomness simultaneously so I enjoy messing with it. If 3 cycles is possible...it is simply beyond me right now, more akin to you, Alec, or Cunning, and beyond reasonable for someone to consider wasting time worrying about a random musing which I wont implement. It is just not interesting enough unless it is related to a current project, like for any of us. If I had a nickel for every random musing I ever had, of course I could retire young and spend the time required to reach that asm skill :lol:

I derailed it...but back to the SPI Vram tile idea, I imagine this is much further down your interest than mine. I sort of don't want to start another game until this works, because my idea to finally make what I consider a "big game" will not work with any mode but this. Simultaneously it is probably easy to simulate/empathize my position, that it would suck to spend the time (I imagine 30+ hours) to *totally* have *all* details working....to then learn there was something fundamentally better I overlooked. So long story short I want to make this a real thing (you already made a good starting point and proof of concept with the scanline code posted previously) and will do the work, but I would greatly appreciate sanity checks along the way!

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests