Weber's Rants (tutorials)

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

Re: Weber's Rants (tutorials)

Post by Jubatian »

Nice! I gave it a try on the real hardware after generating packrom info for it (I guess I will also do something about those tons of missing UZE files now). I couldn't get it play on any of my SDHC cards, however it worked from a slow SDSC.

Why so? For me it seems necessary to load full sectors this case (so you can't avoid using an 512b buffer in RAM) to transfer from the SD into the SPI RAM, so using sdBase for this have no much purpose (especially not with those no CRC calculation sector reads I gave to Artcfox, which is fine for this goal as only some samples will be off when the load fails). Or did you actually use the bootloader API library and so there is a bug in it?
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

Yes it is sdBase for now just because I am used to it, though in a final version would ideally be bootloader API. There are a couple "ifs" there, but my guess is it will be fine. I think it is going to take more cycles, but as long as the menu items still works responsively then SDHC support is really nice to have.

UART is a concern because it is another set of buffers. Another point for a customized HSYNC, since it should be possible to have a user defined pointer(to unused ram tiles), where the buffer can be very large during menus when all this expensive streaming happens. Even at 9600 baud it is very easy for data to be overwritten before it is processed with something like a 24 byte Rx buffer. This way with some code to handle possible multi frame stalls(mainly just making input feel OK still in those cases), it can work. In game it is simpler because it devolves into a guaranteed in order TCP stream of 1 byte pad states. Run as many input states as are available for each car which handles lag and jitter. All pipe dreams..or maybe not!
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

So I just have no time as I work 60+ hours every week. I get frustrated because to jump in and out is so inefficient, and it takes quite a long time to even get all the things loaded back into the mind before you can make progress. I side tracked, but not really. As discussed in other threads I am working on Mode 15 which is required for what I want to do with this game as well as Lolo and MegaBomber which have been sitting close to finished for years. Getting worried for UCC quite honestly, and I may not be able to deliver if things continue as they are. Nothing to do but try and see.

Neither the vsync nor inline mixer is appropriate for the racing game, as sound effects are PCM and there is no music besides the direct PCM writes on the menu screens. I think this is quite valid and worth an additional option for mixers so I will work on that. I don't know how to describe it except as a "null mixer" since there is no concept of kernel channels or waves at all, and no existing music engine will work without those; you either have the right PCM already in the buffer each frame(during user code) or you don't. I envision puzzle and other tile based games in particular putting this to great use, and sprite games limiting music to appropriate situations of course. Current task now, since that is the easiest one to complete.

Edit - should say this is essentially a striped vsync mixer and #defines around music code. Usually vsync mixer is slower since you need to mix the music during vsync. Since not doing that, it should free up hundreds of cycles which can be devoted to filling buffers directly. Unfortunately during screen render lines there is no optimization, since the video mode must wait for the maximum amount of cycles any mixer could take.
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Weber's Rants (tutorials)

Post by uze6666 »

Pretty cool music in your 1 demo! :P For what it's worth, I once did a custom inline "car engine" mixer for somebody who alas never did the game. It's been sitting there since 2013. Perhaps it could be useful for you or someone else. As I recall it was based upon an old arcade machine's analog circuit. It modulates one channel with 2 others something like this:
PJ Mixer.png
PJ Mixer.png (52.07 KiB) Viewed 16791 times
Code is old and terribly inneficient but sounds pretty cool IHMO. :)
Attachments
customInlineSoundMixer.zip
(3.3 KiB) Downloaded 624 times
pjmixer.hex
(28.51 KiB) Downloaded 607 times
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

Very nice, this seems like the way to go for the racing game.
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

Just a personal update from me, I am doing renovations on a house we are moving into and working long hours at work besides. I wont be active much for a while, but I will be lurking the forums as time allows.

The girlfriend *"needed"* to live in a very specific neighborhood on a very specific lake and the opportunity finally arose, so we are moving out of the cities slowly. Original 1959 wood interior throughout, but her tastes are, lets say..several steps fancier than mine. A lot of blood, sweat, and tears are being shed to keep the boss happy. But mostly the dollars; that is what I will miss most! :lol:
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Weber's Rants (tutorials)

Post by uze6666 »

Congrats on the new place Lee, very happy for you! Indeed it's the priority and the boss is always right. :lol: That said, keep lurking your PMs, I'll need your new address. ;)
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Weber's Rants (tutorials)

Post by nicksen782 »

I realized that Toorum's Quest used "_HISCORE.DAT" for the high scores so I updated the Online Emulator to save and load _HISCORE.DAT (all games) and the file never updates. Is the functionality bugged or is it me? If I read into the Emscripten filesystem the file size never changes. So, I made it create a blank file of 512 bytes. Still no change, all zeros.

Are any other games using "_HISCORE.DAT" other than Toorum's Quest and Dig Dug?
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

TQ should write data in the 16th sector from the start of that file, so with a file smaller than that I don't know what would/should happen in an emulated environment. I planned to have AE use that file as well but no released version currently does so. It could make sense to have Emuze have load/save states in this file perhaps, but I have not pursued it very far yet.
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

I'm working on Columns: Uzenet Edition, and I wont go overboard talking about it yet. This will be a new separate game with radical alterations. Basically ditching the CPU player, offloading all PCM and music(like 50% of the ROM there), and using the gains for more graphics and way more music. The CPU player will be available as on online bot in this version I'm thinking(the CPU player is heavy).

Anyway the sound effects are easily offloaded with SPI RAM. The CPU player being gone, gives gobs of cycles and a good portion of RAM to make up for a mixer buffer. I'm aiming for a non-hypothetical demonstration of the full PCM game music idea here. "Wait, is that an Uzebox or a Sega CD?!" :lol: Anyway...
Jubatian wrote: Wed Apr 04, 2018 8:04 am ...
Take the inline mixer, and modify its PCM channel so it reads from RAM instead of ROM, optionally discarding its frequency (so it always increments the sample pointer by 1).

Then you can use the PCM channel as an audio buffer (288 bytes for example) which you may fill in VBlank, even from the SPI RAM, even from within Mode 748. This would both require less RAM and less VBlank time (as it is still an inline mixer). Mode 748 by the way has 234 cycles for the mixer, Mode 74 only 215.
This!! The power here is crazy, because it it attacks the core problem with the SPI RAM audio idea(RAM for buffers, and cycles to fill them). This audio mixer mode would also be useful for something like a SID or NSF player. In all such cases, you would only want to output at the full 15.7Khz anyway.

I'm looking at this like...without the stock channels(besides a simplified PCM one), there are a lot of free HSYNC cycles which could be used for something like a software "DMA" action. Or perhaps just change some registers specific to a particular video mode, based on a buffer of commands. We could reanalyze an idea from a long time ago: User HSYNC Code.

What if when running a PCM mixer, there was an arbitrary chunk of user supplied ASM(maybe Jubatian already did something like this)? This would allow small ASM modules to be combined and selected. Of course the user would need to make sure the cycle count was good, and it didn't clobber registers required by the video mode used.

I could see making the entire HSYNC period filled in with modules, which might just be the stock channels and UART. Otherwise maybe a choice of several DMA types, a single rate PCM player, some mode specific register stuff, or some mixture with SD sorcery? Maybe you just want to make sweet demos with PCM music, and use the free cycles to shift around scrolling offsets and tileset pointers per scanline!

Checking this out, it seems realistic.
Post Reply