Cybearg

I just use a build.bat file I made to compile, assemble, and run the game: @ECHO OFF ..\intybasic main.bas ..\output.asm ..\ ..\as1600 -o ..\output.bin -l ..\output.lst ..\output.asm ..\jzintv -e ..\exec.bin -g ..\grom.bin ..\output.bin I just make sure that the game's primary BASIC file is called main.bas, stick it in a subdirectory of IntyB (which holds the emulator, BIOS, assembler, and compiler) and then just run it when I want to check on changes.

Well now it's not reading my gamepad at all. Thanks for the tips on how to get it to work, but first and foremost, I need a gamepad that isn't a knock-off piece of junk. Anywhere I can get a compatible Genesis controller for a reasonable price?

I was under the impression that was the only way to do it. And yes, I've done the computer restarting thing, though it doesn't really make much sense to me. What about bB would cause lingering changes that could be cleared by restarting your computer? Alright. I made a new project and thought I'd start with as basic as I could get: set romsize 4k set tv ntsc scorecolor = $0E main drawscreen goto main This won't compile. Don't know how to really step back from there. However, this will compile: set kernel DPC+ const splitscore_2_4 = 0 dim splitKernelVar = z const SPLIT_KERN_BIT = BIT_7 goto main bank2 bank 2 main scorecolors: $40 $42 $44 $46 $48 $4A $4C $4E end drawscreen goto main It works with additional scores right up until this point: .byte $00 ; | | $FF70 .byte $7E ; | XXXXXX | $FF71 .byte $60 ; | XX | $FF72 .byte $60 ; | XX | $FF73 .byte $7C ; | XXXXX | $FF74 .byte $60 ; | XX | $FF75 .byte $60 ; | XX | $FF76 ; .byte $7E ; | XXXXXX | $FF77 ; .byte $00 ; | | $FF78 ; .byte $60 ; | XX | $FF79 ; .byte $60 ; | XX | $FF7A ; .byte $60 ; | XX | $FF7B ; .byte $7C ; | XXXXX | $FF7C ; .byte $60 ; | XX | $FF7D ; .byte $60 ; | XX | $FF7E ; .byte $7E ; | XXXXXX | $FF7F Any additional bytes cause it to crash during compilation. It only allows 7 out of 8 bytes of E. If I uncomment one more byte, I get: So at least I'm running out of ROM here before trouble arises. That doesn't really tell me much about why I get problems at other times, though.

Yeah, I really have no idea why it's on the fritz for me. I'm more suspicious of vbB itself, since it has shared computer-wide configurations regardless of where it's being run from.

Okay I followed your directions exactly, Omega. The good news is, for whatever reason, it DOES work! The bad news is that it only works for that default game you posted. if I would try to compile my DPC+ game using the new test vbB/bB I set up with the score_graphics.asm and DPCplus_kernel.asm include from your bB post, it still compiles to an incomplete ROM. Again, that's even while using the vbB, bB, and everything else you posted except it's my .bas file and that's it. That explains why your bB was causing problems; I didn't realize you replaced some files in it.

Must be... The last score digit is just this: .byte %00000000 A single byte definition. If I add more bytes, it still works, but if I remove that single byte, it stops working until I've removed 32 additional bytes (i.e. cut it down to 10 score digits). I have no idea, either. Suddenly the one game won't compile in the directory I'd been working on it in, but copying the code to somewhere else suddenly makes it work. Strange, that.

I did attempt this, but I had read in another thread that the ORG/RORG modifications weren't necessary with DPC+ because it apparently ignored it and managed the memory itself. Apparently not? In any case, I didn't have any luck when I tried to subtract 16 from all the ORG/RORG definitions at the top of the file to make room for two more digits. I only modified versions that I had copied into the local directory so changes would't affect unrelated projects.

Update... Apparently it did change something; now my game won't compile correctly at any time, regardless of whether I used the modified kernel or modified score files or not... Great. EDIT: This includes kernels outside of DPC+, too. Stuff I was working on just tonight now won't compile. What the shit? EDIT: Oh, phew... Just had to restart VBB after making a change in compiler. That was a scare. Checking progress... EDIT: Okay, apparently it wasn't just vBB. I don't know what the deal is, Omega, but the 2600basic in that zip you posted doesn't work... at all. For any kernel or any configuration of any of the games I've ever worked on. DPC+ kernels will compile and get a black screen when run. Non-DPC+ kernels will fail to compile at all. I've restarted vbB multiple times. EDIT: I've tried restarting my computer. No dice. I've copied the latest version of vbB to a new directory, got it set up to the batariBasic Omega linked and... nothing. Still doesn't compile anything. EDIT: Oh, I found one thing it will compile! A 2kb game I played with when still learning bB. Nothing else, though. EDIT: I give up! I hope someone can offer some insight, because I'm about ready to piss boiling water. EDIT: And, again, this problem doesn't happen at all if I use exactly 10 or exactly 16 score digits. Anyone know why that might be? EDIT: Scratch that: this doesn't happen if I have 10 OR FEWER score values OR exactly 16. But 11-15 causes the apocalypse, apparently. EDIT: Well, I managed to squeak by with 15.125 scores (see the attached score_graphics file to know what I'm talking about). It allows me to compile and has just enough free bytes to not break, so, in the immortal words of Bill O'Reill, "FUCK IT!" EDIT: As a final edit, I just want to thank everyone who helped me out here, especially Omega. Don't let my frustration here with things acting weird as an insult, debasement, or demeaning of the work you guys have done. Omega and RevEng, I wouldn't have gotten far at all without you two, so thank you! EDIT: Hmm... Apparently all is not perfectly well after all. While the game using Omega's modified kernel and the score is working alright now, a different game I was working on earlier today now has a compile error where it didn't before. All I get is the same error I got with the non-DPC+ games when I tried to use the bB that Omega posted: Any idea what this is or why it has spread from that other version of bB and now infected the one I've been using for months without issue? EDIT: And if I copy that now-not-working code into another .bas file in a different project directory, it now works. Two files with the exact same code, one works and one doesn't after I switched vbB to the bB Omega posted then back to the one I've been using. What the hell? At least it's not an imposing issue, but I don't like this uncertainty. score_graphics.asm

That's exactly what I was using. I downloaded, unzipped, and set things up to use this one just in case there were any tiny differences. I restarted my computer, etc. Same result--I only get a black screen. Apparently nothing could be garnered from any of the list, asm, or bin files I posted? Maybe RevEng has an idea of what might be wrong here, because I'm baffled. But, again, it DOES work if I have exactly 10 or 16 numbers. I'm just short about 10 bytes from just being able to use 16 numbers and avoiding this blank screen issue. Any suggestions where I can cut those 10 bytes out from in case I just can't get it to compile correctly? dpctest.bas dpctest.bas.asm dpctest.bas.list.txt dpctest.bas.symbol.txt score_graphics.asm dpctest.bas.bin

I should have done it that way, sorry. My fault for being confusing.

I put it in a separate project folder, as you said. As before, it compiles with a black screen for me. I'm afraid I don't know how to compare them, so here's the .bin. default.bas.bin default.bas.asm default.bas.list.txt default.bas.symbol.txt

I get the same thing: a black screen. I really don't think the problem is with me setting those things. As I said, if I use 10 digits it works fine and if I use 16 digits it works fine. 11-15 gives nothing but a black screen. I suspect there is memory being automatically reserved for 10 or 16 digits but if I try to have just 12 then I'm short of the 16 digits it expects. I need to to accept me setting only 12 digits instead of 16 (because there isn't enough space for a full 16 unless you can chop another 10 bytes out of the kernel--then there would be). main.bas.bin

That's exactly what I'm doing already. dim sc1 = score dim sc2 = score+1 dim sc3 = score+2 ... if !split_score then goto __Draw_Main_Score scorecolors: $46 $44 $1E $1E $1C $1C $1A $1A end sc1 = $01 sc2 = $23 sc3 = $45 goto __Main_Draw __Draw_Main_Score scorecolors: $46 $44 $AE $AE $AC $AC $AA $AA end sc1 = $67 sc2 = $89 sc3 = $ab __Main_Draw That's the only place I'm manipulating the score. Again, it only works if I have 10 or 16 score digits. Nothing in between will compile correctly. See the zip I attached to my previous post for the compile.

Essentially that's true, but if I add more than 10 digits to score_graphics.asm and fewer than 16, the game doesn't compile correctly; I just get a black screen as a result. Only when I increase it to 16 total digits does it work again, but at 16 digits, I'm too short on ROM for that to work at the moment. BrokenOutput.zip score_graphics.asm

You're forgetting the counting words, which puts it up an additional 40 bytes. 4 * 5 + 11 * 4 + 5 * 3 = 79 + 20 = 99 words = 198 bytes

I haven't had any luck getting more working. I'm guessing because somewhere the kernel defaults to either 10 (11?) or 16. If I have 10 or if I have 16 (tested by me cutting out a piece of the kernel just to make some space), it works, but nothing in between works.

Gotcha. Now everything seems great except that I need those two additional score digits for $A and $B, but apparently I can't have just 12 digits (if I try and compile, I just get a black screen), so I need either 10 (normal) or 16 (0-F), but 16 digits put me over by 10 bytes... Is there a way to allow for more than 10 digits but fewer than 16 or to shave another 10-12 bytes off of the kernel size?

I've implemented using the MSB of each byte of level data to signify if the following card will be the same. I'm at 69 unique tiles at the moment and I don't think it likely that I will have 128 unique tiles in the entire game, and certainly not within a single map. If I do, I can always have separate card tables for different stages/maps/whatever. It should be good, though. Before, in the first 20 columns of my map data, I had: Now I have: 0 columns with 6 data words 4 columns with 5 data words 11 columns with 4 data words 5 columns with 3 data words 0 colums with <3 data words That's some big compression where it counts! By my earlier estimation, the compression brought 240 bytes per screen and 2400 bytes per level (from the 480 bytes per screen it would take to write raw BACKTAB words) down to 220 bytes per screen and 2200 bytes per level (with basic encoding). Using these first 20 columns as a sample, it's now down to 198 bytes per screen and 1980 bytes per level. Assuming one level (or all levels) use no more than 128 unique words, that's a total of 21728, 19928, 17948 words for all map data, respectively. Now, the only other big space saver I could see would be that lower nybble of the counting word that is always wasted. If I packed 4 bits of the 4th counter word into the preceding three counter words, I could cut 1 word every 3 columns. That would be a savings of 5 words per screen, or 50 per level -- about 900 for the entire set of map data. Might be worth pursuing. And there's no catch to it, either, aside from the processing cost of decoding the fourth counter word.

I didn't know how doable it would be. I'd never tried using an encoding algorithm bfeore and sounded pretty beyond me.

Add a request for Intellivoice support in there.

Out of curiosity, have any of those tough nuts been cracked?

Yes, though it's getting more complicated, now. I might have to take some of this stuff in baby steps.

Each statement is one column, yes. It starts with the 12-bit redundancy code (which is why the lowest nybble is always 0) and is followed by the new data in the form of words.

Awesome, thanks so much, Omega! By the way, is there any way for me to gauge how many cycles I'm using in DPC+? set debug cyclescore doesn't work, but I'd like an idea of where I'm at. Is there any way I can tell?

So I just have to subtract in BCD mode, such as: dec variable = variable - 1 temp1 = variable2 & $0F temp2 = variable2 & $F0 if !variable && temp1 then dec variable2 = temp1 - 1 + temp2 if !variable && !temp1 then variable = 0 ... And so on?