Jump to content


  • Content Count

  • Joined

Community Reputation

97 Excellent

1 Follower

About Lillapojkenpåön

  • Rank
    Chopper Commander

Recent Profile Visitors

3,938 profile views
  1. Yeah I tried the sequential variables both in regular ram and dpc ram but when i pushed fire which was suppose to change the color of the sprite, i just got different color on each line that moved upwards, but I'm a noob so if you can get that to work I would appreciate it
  2. Hmm how do I ask this.. Let's say you could shoot enemies all over the screen, and that when an enemy is shot something travels from it's location down to the score, but I want it to allways take one second to travel there even if it's far away or close to the score, you would have to calculate a 8.8 speed that makes the thing reach it's destination within said time, possible? anybody know of some similar code?
  3. I have made an example that can do that, allmost exactly the same If someone can color an entire sprite the color of a variable without tables that could be usefull tho, that's what I wanted to do originally that led to these examples.
  4. I have this setup, it's the most popular for making cartmods, don't think you need the adp-054 adapter for 2600 https://www.ebay.com/itm/PRG-113-GQ-4X-Willem-Programmer-ADP-054-16-Bit-EPROM40-42pin-Tool-007-UV-Eraser/112220589648?hash=item1a20de4e50:g:6iMAAOSwcH5cEZ7s I have made nes, snes, master system and mega drive carts with it, never atari 2600 tho.
  5. Nice! I beat the boss, I might have taken a shortcut because I got shot into a wall and jumped in the wall mario style up to the next level
  6. Since memory addresses are 16-bit such as $1234 you have to split it up into two bytes < takes LSB (least significant byte) aka low byte, the $34 part of the address > takes MSB (most significant byte) aka high byte, the $12 part of the address $12 would be the page and $34 the location on that page, a page has 256 different locations. I'm shure PFCOLS is the beginning of a page so there's 256 bytes until the next page begins, that way the high byte that holds the page never has to change. I'm not shure what address PFCOLS is, but let's say it's $0700 $0700 ; holds the first color $0701 ; second color $0702 ; etc.. $0703 then when compiling our previous example lda #<(PFCOLS+6) ; point to the sixth byte in the color data sta DF0LOW lda #(>PFCOLS) & $0F sta DF0HI the compiler first replaces the labels with the values: lda #<$0706 ; point to the sixth byte in the color data sta DF0LOW lda #>$0700 sta DF0HI It then extracts the MSB and LSB: lda #$06 ; point to the sixth byte in the color data sta DF0LOW lda #$07 sta DF0HI then you will push to $0706, I did not explain the & $0F since I don't know what it does myself?
  7. This is just a simple fix for the top two lines having the same color ;*************************************************************** ; ; 88 rows that are 2 scanlines high. ; DF6FRACINC = 255 : DF4FRACINC = 255 DF0FRACINC = 128 : DF1FRACINC = 128 : DF2FRACINC = 128 : DF3FRACINC = 128 asm LDA DF6FRACDATA ; bgcolor priming read (first value will be read twice) LDA DF4FRACDATA ; pfcolor priming read (first value will be read twice) end ;*************************************************************** ; ; Displays the screen. ; drawscreen
  8. I might be wrong but this is how I understand it.. I recently had to ask about the constants myself and why you couldn't just do this DF0LOW = #<(PFCOLS) DF0HI = #(>PFCOLS) & $0F RevEng had this to say: "the "#" "<" and ">" value modifiers don't really belong to the language proper, they come from assembly language. So the parsing that happens during regular variable assignments doesn't work with them, but the const command doesn't do any parsing and passes them to the underlying assembly code intact" So it's just a workaround to get the correct values when using bB, if you use inline assembly you don't need the constants asm lda #<(PFCOLS) sta DF0LOW lda #(>PFCOLS) & $0F sta DF0HI end If you open bB.1.1d.reveng41 / includes / DPCplusbB you'll see that just like A is a nickname for a RIOT RAM address, PFCOLS is a nickname for a DPC RAM address, and the next 256 bytes after that is reserved for playfield color data, the kernel points a Fractional Data Fetcher to that data.. lda <PFCOLS sta DF4FRACLOW lda (>PFCOLS) & $0F sta DF4FRACHI then reads that data every other line and stores it to the colupf register lda #<DF4FRACDATA sta COLUPF how often the colors are updated depends on how you set up DF4FRACINC before drawscreen DF4FRACINC = 255 will increment the fetcher after every read and update the color every other line DF4FRACINC = 128 will icrement the fetcher every other read and update the color every fourth line etc. These fetchers are part of why there's time to do so much in the DPC+ kernel, because they increment automaticly after each read, depending on how you primed them. Anyway, this code just points to the color data and pushes new values into it, here's an assembly example if that makes more sense, if you wanted three rows to be white, and those three rows to be another three rows from the top of the screen asm lda #<(PFCOLS+6) ; point to the sixth byte in the color data sta DF0LOW lda #(>PFCOLS) & $0F sta DF0HI lda $0E ; white sta DF0PUSH ; changes the sixth byte/row sta DF0PUSH ; changes the fifth byte/row sta DF0PUSH ; changes the fourth byte/row end
  9. Then just turn on one pfpixel instead of many, same thing.
  10. I don't think I've had anything adapted to the bB page before so that would be cool, even just linked would make me feel good, both would be awesome!
  11. Here's some bB examples of stuff that's not easy to figure out, so might save somebody some time. Change color behind score without minikernel CHANGE_COLOR_BEHIND_SCORE.bas Change scorecolor SCORE_COLORCYCLE.bas Change playfieldcolor on any row/rows you want CHANGE_PLAYFIELD_COLOR.bas Change backgroundcolor on any row/rows you want CHANGE_BACKGROUND_COLOR.bas I'll try and come up with some more.
  12. Oh, I found the latest executable https://www.bennugd.org/downloads/bgd-1.0.0-r348-win32.exe bennupack is probably just some other usefull things. But everything you need is in BennupackDreamcastDevKitR20170414, nothing else required http://amelian.eu/blog/2018/05/31/tutorial-bennugd-para-sega-dreamcast-gestion-de-memoria-ram/ http://amelian.eu/blog/2018/06/12/tutorial-bennugd-para-sega-dreamcast-assets-y-colores/
  13. I stumbled upon this, from what I understand it's a high level language with support for dreamcast? apparently it's also very easy to port your projects to alot of other systems, it sounds amazing but surprisingly I can't find much information about it? I registered at dcemulation but got no mail so maybe someone here can help me. I can't figure out what to do with it!? How do I install it? Bennupack 2.9 https://sourceforge.net/projects/coldev/files/bennupack/ BennupackDreamcastDevKitR20170414 https://sourceforge.net/projects/coldev/files/Dreamcast/ I found this not up to date tutorial, but my bennupack doesn't have a .exe https://translate.google.es/translate?sl=es&tl=en&js=y&prev=_t&hl=es&ie=UTF-8&u=http%3A%2F%2Fwww.segasaturno.com%2Fportal%2Ftutorial-bennugd-de-indiket-para-dreamcast-vf19-vt8570.html&edit-text= There seems to be alot of examples to learn from if I only knew how to use it?
  14. Cool! I never would have thought a complete version of Jim Power (with complete Chris Huelsbeck soundtrack) Time Trax or Hardcore would ever surface and was kind of obsessed with finding them, but now they are all in safe hands, just waiting for two rom dumps so I can make some cartmods
  15. Why are the constants important? Would this not work? mempointer = #<mydata mempointerhi = #>mydata
  • Create New...