Відео

This is VIC-II, the VDC can shift a screen in "lines" of VBlank, while it can shift a bitmap in ~2.5 frames. If you want to see how fast VDC bitmap scrolling is, have a look at Bucket Wars 1.3 128 on CSDB. Then compare it to the +4 and C64 versions.

@@oziphantom9465will do, thanks! Great stuff on your channel. And I also highly value your contributions on the c128forum. Thanks!

Blocks of RAM are used, typically you use it with a separate not overlapping RAM. so for example on a more modern computer you would have a Block of VRAM and Block of Main RAM so they don't Bank over each other. But the Compute's Mapping the Commodore 128 book ( top read if you don't know it ) also refers to the two 64K "Banks" as "blocks" as they are "generally" not overlapping RAM that is not continuous.

thank you, sadly nobody was watching.

I also can't figure out what DMAZero is.

LDA #$FF00 STA $4201 puts 00 at 4201 and FF at 4202 which as you have noted is incorrect and it should be LDA #$FF00 STA $4200 which puts 00 at 4200 and FF at 4201

@@michaellinke6448 DMAZero is a label in memory that points to a 0 byte/word that is in the ROM. I.e it a memory location the DMA engine can read from that will cause it to read a 0. You can't give the DMA engine a Value it needs a source address that holds the value you want.

​@@oziphantom9465 so it's labelling an address where you can find $00 00? In my case, LDA #loword(ZeroAddr) STA $4302 ... ZeroAddr: BRK BRK ZeroAddr happens to live at $8129 right now. I want to send the address, of $8129 to $4302, if I understand you? Eg LDA #$8129 STA $4302 in my debugger?

@@michaellinke6448 DMAZero .word $0000 I didn't put anything up for Vid2 as you kind of need to get to vid4 for anything useful but whole code and other examples can be found here github.com/oziphantom/ElementsSnesEngine

simple answer yes more complex answer, no, you can change the sprite base address at any point, you can also switch the sprites "upper bank" to 1 of 4 positions at any point. However this is rarely practical and needs careful planning.

A Mega 65 utterly destroys a CX16, its not even a fight. The Mega 65 has extra tricks that on paper don't show the true power. The Raster Rewrite Buffer tech is Amiga 1200 melting power, in that you can use more pixel time per line to make as many layers or sprites as you can fit in the pixel fill time. See this video for details ua-cam.com/video/00bm5uBeBos/v-deo.html on top that it has a programmable DMA engine that gives you better than a Atari Lynx bliter object drawing as well, and the engine runs at the full speed. Then it has insane amounts of CPU power, lots more RAM, a MMU, hardware multipliers and 32bit maths operations, and the Video RAM is memory mapped like a C64 not stuck through a port making it easier and faster to access.

256 sprites is a nice update, however if you watch my other videos, I think it was the Ports one, been a couple of years. Updating all 128 sprites via the port with manual loops is an issue, doubling that is going to take twice as long, that might not even fit inside NTSC VBlank, and sadly there is no PAL mode.

not seen the actual expansion port layout to see if it has the DMA/AEC/HALT pin available to stall the 65C02 and let an external CPU take over the bus, but I would imagine it is there or some other mechanism is.

Excellent catch, the github code has been updated. Thank you.

I feel it is neater and shows the intent more clearly, i.e this is a dummy byte used for alignment rather than just an unknown byte just hanging in the struct. It's a style thing mostly.

=($0400,$0828,$0999) and the rest of the assembly. I probably should have put the 'This results in' audio a bit later. But I'm showing you the 64rass commands and then it scrolls to show you the assembler output.

empty space. Say for example you punch, then you have a lot of empty space above and below the arm. Apply this to every animation frame across the entire game, and you just wasted a lot of ROM space. The arcades do this because the machine is a few thousand and who cares, but for the high volume product for a lower price, every chip counts. So pack the parts of the frame down as much as you can, pack as many frames as you can and maximize profit. Every 50c saved on the cart is few million dollars extra profit. Then you also have the DMA the empty space, wasting crucial DMA time that they already had to Letterbox the game to handle worse case frames for NTSC.

@@oziphantom9465 But if the characters do take up most of the space and the machine can get them onto the screen, which I expect is all entirely possible, it's just down to mostly saving the pennies then?

@@inceptional they mostly do, but then you can't also share the pieces across all the frames, so you could end up with a 64x64 and then 8x8 to patch fix it, but its probably a net loss overall. 8x8 and 16x16 gives you the highest piece reuse. I do agree that 8x8 and 16x16 was an odd choice, personally I think 32x32 and 8x8 probably would have been a better one. But its one of those things that until you get all the sprite data and try and cut it up, you can't quite be sure. In that is might be fine until you get to Sagat or something and he just breaks it for everything. And the SNES can only have 2 types of sprites, so it one character is built with 8x8+32x32 and another is 8x8+16x16 your screwed. It sold 6.3 million, so if you save 1 penny per cart, you just made $63,000.

because it's "Machine vs Machine" and there is no machine anywhere near powerful enough with a Z80 in it to compare. Then a 3.58mhz Z80 kinda trades blows with a 1mhz 6502, a 65c02 and 8mhz is just a bloodbath.

You are talking about the long addresses? You don't have to do it the way I'm doing it, you could add the addresses to the local memory map or tell the assembler with @w that you want it to take the value as a 16bit address. The problem is the SNES has a lot of mirroring which doesn't make sense in a 65816 context, to the 65816 each 64K bank is unique. I've just forced it to be this way so its harder for a beginner to make a mistake and not write to the raw register when then mean to write to the mirror label.

​@@oziphantom9465 Yes, the STZ longs. I've run into errors from the assembler trying to interpret `PEA label` as a long address, even though PEA can only use a word address. It seems even less intuitive for the assembler to allow it with the address specified. Maybe this makes more sense if you've programmed for other systems. I've only learned assembly for SNES so far.

Ok so the disconnect is. On a Snes 802100 is the same address as 002100 and you tell the assembler you want to write to 2100 and that is the same if it is 80 or 00. Of cause 402100 and C02100 are not the same as 002100 or 802100. This is because the SNES does mirroring, this is a SNES feature not a 65816 feature. On a 65816 002100 is 002100 and 802100 is 802100 and 402100 is 402100 and C02100 is C02100 those are 4 different addresses that access different things. So if you are in bank 802100 and you just tells 64tass you want 2100 it sees that as 002100, which is a problem because you are in 80XXXX. The Assembler is helping you, just on the SNES this is "not important". If you look at historic snes code you will see all kinds of odd symbols to "fix this issue". #!Label etc 64tass has multiple ways to solve this issue. stz@w $2100 ; tell 64tass to only take 16bits and use ABS addressing mode stz $2100,b ; tell 64tass that this is Databank relative and should only use 16bits stz <>$2100 ; tell 64tass to take the lower word of the passed param alternatively you can have a label defined in each bank, so when the label data bank and your current set data bank match, it will auto optimize the bank byte away for you. Basically the assembler is doing exactly as your code tells it to, and it is double checking you are doing what you want to do. I.e you tell it PEA LABEL and it say "no no no, LABEL is not in this bank, that won't work, this is not doing what you think it is doing, i.e you can't push the label from this databank, it needs 24bits to specify that actual memory location". Other assemblers that are designed only for the SNES will handle internal mirroring for you, but the rest of the assembler is under powered compared to the 64TASS and its extensive feature set. I would like 64tass to get SNES mirroring built in, but Soci/Singular will only add it if enough people are actually using it. Making a Chicken and Egg problem.

by expanding the background, you mean zooming using the Mode7 Param? No, there is no "frame buffer" so the zoom is done as it draws it down the screen live. This changes the size of each pixel, but each pixel is only stored once in VRAM still. So you can zoom or compress it as much as you want it still looks the same in VRAM. you can have upto 16K you are free to use as little as you like, no VRAM is hard allocated to be anything ( well Mode 7 is ) so if you only need 4 sprites then you can only alloc 4 sprites worth and use the rest of the data for something else. See the charset for BG3 hidden in the bottom rows of the screen example for ideas on how to pack data in and around places.

@@oziphantom9465 Many thanks! It was my understanding that the space available for Sprites in VRAM was limited to 16 kb. Hmm, I'm going to rephrase the question: Could you use more space for sprite tiles? If I wanted to use 32kb of space for sprites, could I do it? Sorry for asking so many questions, recently I became interested in these topics

@@allbundy432 The SNES can only see 16KB of sprite data at once, if you want 32K you can but you can only choose sprites from a 16K chunk. You can split the upper 8K of sprites into 4 banks, so you can have a fixed 8K and then 3 upper 8K banks that move through frames. But any sprites you want to have on the screen at one time will have to be in either the fixed bank or the upper 8K bank you choose. You can swap the sprite base pointer to toggle between two 16K banks if you want per frame.

@@oziphantom9465 Thanks for your quick response. Could this be a limitation to be able to display several different sprites? Limited to a maximum of 16KB of sprite data to display, repeating the same tiles could add more elements but these being repeated. I am in a project in which I have to show 5-6 different enemies, each one made up of 10 sprites (between 8x8 and 16x16), and I am having a hard time showing them on the screen.

@@allbundy432 now you understand why Final Fight on the SNES only has 2 different enemies on the screen at once. Why the Turtles games have foot men with different palettes only. You could put a couple on a BG as long as they don't overlap on the Y. You can also sort sprites and switch 8K banks down the screen, this will get more on screen but you will have Y placements and overlapping limits. Which may or may not work for you.

layer 2 and 3

@@oziphantom9465 BG2 and BG3

a complex algorithm based on heuristics of how many banks you have on average in a snes title (0.03) combined with how often you want to use more than 8K to which I average screen map plotting, decompression, text building and then rounded to the nearest 0.5%

@@oziphantom9465 cool thx, I'd be curious to learn more about that but it sounds quite esoteric

the sprite or part of the sprite will disappear, if you have ever played a Konami game, you will have noticed flicker on the explosions. That is the sprites "dropping out"

people who program Commodore 64s know the pain of 9bit maths.. since a Commodore 64 is 320x200 pixels.

sorry I didn't get emails for these. Yes you can have SLOW LOROM, FAST LOROM, SLOW HIROM or FAST HIROM the ROM speed doesn't determine the layout.

I need more context, do you mean as in the 64tass name? 64 stands for Commodore 64.

@@oziphantom9465 yeah the name 64tass. So it was developed for C64 but supports 16-bit snes as well.

@@jefflinahan5853 in the beginning there was Turbo Assembler (TASS) for the C64, then expanded to have macros Turbo Macro Pro, then it got ported to the PC as TMPx and 64tass, then it got expanded. The Commodore 64 and 128 have what is known as the SuperCPU 64 and SuperCPU128 which adds 128K and 20mhz 65816 to either, to 64tass support the 65816 for those platforms. Hence it doesn't natively support the weird SNES bank mirroring as its not a "SNES" assembler per se.

no, that would be a horrible bug producing mess, or a great testing system depending on how you look at it. Somebody did write a system ( for nes I think it was ) that will randomize the positions of functions. The problem with code is you need to know exactly how big each function is and what it also needs etc Data can be easier but then also does have cases that rely upon some data following other data directly which makes the process messy

@@oziphantom9465 ok, I don't think "random placement" is a good term then for the linker's strategy. What would give more insight?

@@jefflinahan5853 so you mean "put this in bank X and I don't care where" "random", Ca65 and WLA-DX will both do this. I think WLA-DX goes one further with "put this in some bank somewhere" however this comes with the cost of "you will need to tell the assembler exactly what size you want everything to be, i.e lda.b lda.w lda.l so it can use the correct DP, ABS, Long format for address, as the linker can't modify the opcodes and adjust all the other code to shrink or expand to accommodate the change in param size. It will just push it through and you will get a lovely crash. using sections you can basically get this, just .section bank80 ; what ever you want here .send and that will put it somewhere in bank80 for you. You will need to handle moving thing between banks but it is usually a good idea to do that manually as you will want to make sure anything that is set up to do it with ABS has the right data bank address set and you don't break things.

www.popelganda.de/relaunch64.html

No, the pi1541 full emulates the 1541 in "disk mode" so you can use the AR cart with it just fine.

yeah this is a "in the trenches" video.

the MVN/P works best when you are doing "from ROM" as you will want to set and update the SRC pointer as well. While "from buffer" it is more optimal to leave the SRC alone. If only Nintendo made the order setup, dest, length, src. So unrolled loops of DP load (not index) and then an abs store still gets you 7 clocks, but you skip 3 bytes. If you do it in words, then it will take 9 clocks per 2 bytes.

Thanks, I did my maths with 2bit not 4bit (/)_.

yeah but are you using an actual MD or an emulated one?

@@oziphantom9465 What are you talking about?

are you comparing FM vs SPC-700 or 'FM as implemented in the MD' vs SPC-700? FM is basically vector music, so in an emulator you can build the music at a much higher resolution, while the SPC-700 is basically raster music, you get what you get, you can fudge this and that here and there but basically it doesn't get much better.

@@oziphantom9465 I'm not comparing Megadrive anything. I never said I was. FM is still used a lot in modern music production, but nobody uses a sampler with 64k of RAM, save for a few retro composers. I have no clue about the FM in the Megadrive, but I know the Adlib/OPL2 of the PC world sampled at around 50khz, which is far beyond human hearing already, and beyond most modern music production, which is done at 48khz. I'm very happy the X16 has an FM chip instead of a sample synthesis cripplingly limited by RAM. :)

I forgot the YM2151 wasn't culled from the machine, so the CX16 does still have some FM and not just sample + PSG. OPL2 is leagues ahead of the YM2151, the OPM is a massive step down. Even with only 64K the SPC-700 easily outclass it. Nobody uses the OPM/OPL/OPL1 or OPN anymore either. the SPC-700 was upgraded and used in the PS1 and PS2.

Nice work, you don't have VSync enabled, which I think mine does, due to its origins. I spent 3~4 days on mine I think, its only purpose was to put into the video ;) Sadly I can't modify the video or even add an Annotation these days on you tube. But I will pin it and add a link to the insert video of the ST-NICC.

@@oziphantom9465 Thanks! Indeed VSync is not enabled. If I did it would probably be around 15 seconds slower. Thanks for pinning it!

Yeah, he forgot to mention the sprite size modes themselves.

I'm covering more how to design the engine, for the details on each register etc I feel people might as well just watch the RetroGameMechanicsExplained videos about them. But point taken. I want do a video on DougFF's meta sprite maker program, so I will talk about it then, in a design decision context.

I think this is really the only practical use for it. Given it has to go to a port and ports are always inc, so you can't use it to shift ram up either.

probably not. smooth controls are mostly what makes the game fun. 1 frame of lag is known to be death on the original version.

@@oziphantom9465 I suppose, but there are many games which don't have high frame rates on vintage computers, and these games are still fun.

which part do you think needs more detail, or what have I failed to explain it would benefit from? I'm happy to do it again ;)

@@oziphantom9465 Hi, can you please get in touch with me on my discord. Check it on my UA-cam channel front page or info. I tried to find how to get in touch with you over here but couldn't locate it.

well you need an extra 0 but where are you putting the *=$808000 and what do you want to achieve? are you saying why can't we just put *$808000 and avoid the * = 0 .logical ? Because the assembler will start at *=$808000 but then when you want to go the next bank at $818000 it will fill in the 32K between the banks for you as it sees it as a single block. You could do the first one as just *=$808000 and then start doing logical to pack the next banks in if you wanted to.

@@oziphantom9465 yes that was what I meant. I’m not familiar with this kind of banking, I’ll read up some on the .logical in the manual as well I think