Lillapojkenpåön

I do remember this happening before when I was really low on memory left, but I'm not now. I also remember that this started happening right after VS code introduced some "secure something??" where you had to mark the source as secure or something? It has never popped up after the first time and I never understood it. I also remember asking someone about it who said I had to mark the emulators as secure in windows? I don't know how to do that and I can't find any evidence of that conversation taking place.

I prefer the rows wording over scanlines, and not having to download anything. Both are missing the same thing I think, being able to choose different rows for pf, fg and bg color. For my scrolling platformer I have square pf pixels (22 rows) DF0FRACINC = 32 : DF1FRACINC = 32 : DF2FRACINC = 32 : DF3FRACINC = 32 but I color them with 88 rows of color, DF4FRACINC = 255 I understand you can just make two different ones and take the different data from each, but would be pretty nice to see the finished product if you want something to chew on ? If you do, consider adding the space saving option "single color" example: bkcolors: $00 end DF6FRACINC = 0 If not, an online sprite editor like Lewis suggested would also save alot of time.

Yes it allways used to work, but I guess it was why I took a break. No makefile, no errors, I've tried many both 2600 and 7800 sources that I know should work. bB stops at Moving debugger file(s) to 'bin' folder... and there is a bin file with correct size and date that runs if I open it in Stella manually I tried inputting the path to the Stella I ran it from manually, but it made no difference. 7800basic also stops at Moving debugger file(s) to 'bin' folder... Only system change I can think of is that I installed IntyBASIC SDK

I have no idea what the problem might be, any suggestions?

Wow, that playfield editor is gonna save alot of time, PERFECT! ? Have you tried if 176 looks correct with no priming reads at all? looks like it would, or with the same ones as 88, using an unmodified kernel? and what happens to 44 and 22 for example with them? I assumed those two lines of assembly code would work for any normal row number, If it doesn't a better fix for RevEng for the next release would be to find out what changed in the driver that prevents it from working now and change that back, or just change the driver if it doesn't break anything. the playfield editor does the rest.

I had a break, how come the 7800 or 2600 emulators doesn't show up when I compile and run?

Sorry for being inactive. but good to know I wasn't imagining this working on real hardware once. I noticed as soon as this stopped working and tried to describe it to stephena with little success, I thought it was an emulator bug since it stopped working with the ADS update where Stella looked drastically different, but I moved the priming reads to the kernel, after the start positions in VRAM has been set, and it worked, so I told stephena that it wasn't a bug that it didn't work, if anything probably a bug that it used to work (it wasn't that either) I put it with the other priming reads and everything worked fine, I also reported it to RevEng who added it to the github master. setloopfrac lda dffraclow,x sta DF0FRACLOW,x lda dffrachi,x sta DF0FRACHI,x dex bpl setloopfrac ; lda #255 STx DF5FRACINC ; x=255 right now STx DF7FRACINC lda DF5FRACDATA ; priming read lda DF7FRACDATA ; priming read LDA DF6FRACDATA ; priming read (so first bg color value won't be read twice) LDA DF4FRACDATA ; priming read (so first pf color value won't be read twice) ldx SpriteGfxIndex lda _NUSIZ1,x ; top NUSIZ/REFP sta NUSIZ1 sta REFP1

Thanks! #BACKTAB(y*20)=level1(y*DATACOLUMNS+#x) It was 38 in my example.

My brain has stopped working, I want to scroll horisontally, what would be the best way to read column 20 of the table, and also be able to make the level as big as possible? Something like this, obviously super wrong since I'm not considering the length of the level, and I'm not trying to use an array, just control the offset dim #x #x=19 RESTORE level1 FOR y=0 TO 11 READ #line(y*20+#x) #BACKTAB(y*20)=#line NEXT level1: DATA GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW,GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW,GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW,GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW,GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW,GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW,GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW,GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW,GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW,GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW,GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW In bB I hade to do alot of manual inc and dec of the high byte of the pointer to do this, and made a program that output my level data column by column instead of row by row

Thank you! I really appreciate it! A little to late, but here's what I was trying to do, background collision check but using fixed point variables for the sprite It took a while to get right but it works perfectly now thanks to all the help I get. If you see anything I could improve please let me know. Thank you! DIM #X0 DIM #Y0 #X0 =16.0 #Y0 =16.0 DIM overlap DIM #line CONST tileHeightMask = &00000111 CONST tileHeight = 8 CONST tileWidthMask = &00000111 CONST tileWidth = 8 CONST pfDiff = 8 CONST spriteHeightMinusOne = 3 CONST spriteWidthMinusOne = 7 'top and bottom row and left and right column of sprite DEF FN top = ((#Y0 AND 255) - pfDiff) / 8 DEF FN bottom = (((#Y0 AND 255) - pfDiff) + spriteHeightMinusOne) / 8 DEF FN left = ((#X0 AND 255) - pfDiff) / 8 DEF FN right = (((#X0 AND 255) - pfDiff) + spriteWidthMinusOne) / 8 InfiniteLoop: IF CONT1.UP = 0 THEN GOTO skipUp #Y0 = #Y0 -. 1.0 overlap = tileHeight - (#Y0 AND tileHeightMask) #line = #backtab(right + top * 20) IF #line = GW THEN #Y0 = #Y0 +. overlap : GOTO skipUp #line = #backtab(left + top * 20) IF #line = GW THEN #Y0 = #Y0 +. overlap skipUp: IF CONT1.DOWN = 0 THEN GOTO skipDown #Y0 = #Y0 +. 1.0 overlap = (#Y0 AND tileHeightMask) - 4 #line = #backtab(right + bottom * 20) IF #line = GW THEN #Y0 = #Y0 -. overlap : GOTO skipDown #line = #backtab(left + bottom * 20) IF #line = GW THEN #Y0 = #Y0 -. overlap skipDown: IF CONT1.LEFT = 0 THEN GOTO skipLeft #X0 = #X0 -. 0.5 overlap = tileWidth - (#X0 AND tileWidthMask) #line = #backtab(left + top * 20) IF #line = GW THEN #X0 = #X0 +. overlap : GOTO skipLeft #line = #backtab(left + bottom * 20) IF #line = GW THEN #X0 = #X0 +. overlap skipLeft: IF CONT1.RIGHT = 0 THEN GOTO skipRight #X0 = #X0 +. 0.5 overlap = #X0 AND tileWidthMask #line = #backtab(right + top * 20) IF #line = GW THEN #X0 = #X0 -. overlap : GOTO skipRight #line = #backtab(right + bottom * 20) IF #line = GW THEN #X0 = #X0 -. overlap skipRight: SPRITE 0, #X0 + HIT + VISIBLE, #Y0, SPR16 + sprite0FRAME*8 + SPR_YELLOW WAIT GOTO InfiniteLoop

Yup, except I still can't figure out how to add or subtract an 8-bit variable to or from the integer part #h = #h + overlap * 256 'nope #h = #h + overlap 'nope #h = #h +. overlap.0 'nope #h = #h + #overlap2 'nope

I just wanted some easy to use 8.8 variables with fractional increments of the high byte, but sounds like it would be alot faster to just use two bytes and a little bit of logic to do the same thing.

Something like this, to have easy access to the two bytes? DIM #h DIM h1 = #h DIM h2 = #h + 1 And how come the sprite have to be placed at x8 y8 to show up in the top left corner of the screen instead of x0 y0?

Is there a way to DIM the two bytes of a 16 bit variable?

Thanks! I can't find a way to do text replacement? The way you would hide bit operations in bB def m0Up=c{4} if !m0Up then..

Thanks! that's perfect, I'm gonna go through that wiki now.

Ofcourse, what I meant was that allmost everything I've learned so far came from me trying to do a loop instead of use SCREEN, which I was able to use by just copying code from examples without knowing what it did, but I want to learn the architecture, and what it copies, from where to where, I had allready put this comment from the intyBASIC manual by my SCREEN statement 'This statement is the fastest way to copy screen data to video So I intend to use it, the loop is just for learning purposes.

Yup that's pretty much exactly what I've got but alot prettier, and I'm also trying it with GROM characters after a successful GRAM test, I understand SCREEN might be faster, but I'm not learning anything by using it, I'll use it later. I seriously didn't know intellivision could do graphics like this! I'm so hyped!! INCLUDE "constants.bas" CONST GW = $0000 + 25 + FG_BLUE + BG_ORANGE MODE SCREEN_FOREGROUND_BACKGROUND WAIT DEFINE DEF00,1,bitmaps WAIT DIM offset DIM #line RESTORE level1 FOR offset = 0 TO 239 READ #line #BACKTAB(offset) = #line NEXT offset WAIT loop: WAIT GOTO loop bitmaps: BITMAP "########" BITMAP "#......#" BITMAP "#......#" BITMAP "#......#" BITMAP "#......#" BITMAP "#......#" BITMAP "#......#" BITMAP "########" level1: DATA GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW The WAIT command after MODE fixed my first issue Don't know why the different characters have different colors instead of just being blue? As I said before my other issue was just that the compilation failed because of a missing colon, so the emulator ran an old build, made it seem like changing $0800 to $0000 had no affect.

Lol, my builds have been failing for a while and my batch script ran the last working bin, so that explains the GRAM card, still don't know how to use the mode tho.

Thanks!! I tried MODE SCREEN_FOREGROUND_BACKGROUND ' Set foreground/background mode and added a bg color to a card CONST GW = $0800 + 0 + FG_BLUE + BG_TAN but that was apparently not how you use it I also tried not using $0800 but it just uses my GRAM card no matter what number I use? NO! Not good time but good to know about in the future!

Thanks for answering everything I was wondering comrades!!!! Is 8 sprites, 228 8-bit variables and 47 16-bit variables an intyBASIC thing or an intellivision thing? If $0800 turns on the GRAM bit could I use some number in the table to turn on a GROM bit to copy GROM numbers to BACKTAB and use the same code, or do you have to use PRINT for those? What's up with the rightmost pixels not being drawn?

Thanks! I've drawn the character backgrounds allready, I can't find a game3 tho? Other than the unnecessary nested loops, what am I doing wrong here? RESTORE level1 FOR y = 0 TO 11 FOR x = 0 TO 19 READ #line POKE BACKTAB_ADDR+x*y,#line NEXT x NEXT y WAIT level1 DATA GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,WE DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,WE DATA GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW

Thanks! I like that alot better. I would prefer FOR loops since that's what I'm used to, but have'nt found an example of that yet, just started experimenting and still very confused. I'm guessing this CLS DEFINE DEF00,16,bitmaps WAIT copies the tiles to GRAM starting at $0800, says it's for Background GRAM cards, does cards mean 8x8 tiles basically? I define my sprite in the same way so it also end up there, guess it counts as background? tile indexes get stored to $0000 and forward. So I'm a little confused what the for loops would do if all the graphics are where they are suppose to be? Color them and make them visible? Or do they need to be copied to somewhere else? Now that I wrote it down it seems pretty reasonable that the define just store the indexes and I have to copy the tiles to GRAM? But I don't have to do that for the sprite??

I'm looking at this example and wondering how you make a new level? Start with garbage tables and slowly enter new numbers? It would take a long time to build levels by entering numbers and not seeing how the level is gonna look, but maybe you get used to it?

So is the ARM code also constantly checking if there's a bankswitch hotspot or datastream address on the address bus? And if there is code is executed to do the inc or bankswitch?