Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

BrianBeuken

Members
 View Profile  See their activity

  • Content Count

    37

  • Joined

  • Last visited

Posts posted by BrianBeuken

  2. Posted

    Hi all

     

    I wonder if I can get some collective help for a strange problem I am having.

    i've been working on a CV game for some time now, its a collection of mini games and a menu system to tie them together and code wise its all done and dusted, it works perfectly on every emulator I have found, but when I test it on hardware I get a very strange and apparently random corruption of my sprites but only on some of the games, and not always the same ones.

     

    I am using the correct terminators in the sprite list I send to the video. and I even make an extra effort to ensure the sprite attrib memory is filled with 192's before I dump my sprite list. but on some of my sub games, the sprites just go crazy.. I can reposition the games and the issue vanishes, though will crop up in another game or not appear again unless I add a few bytes of code. I don't have enough memory now to actrually just add padding until it stops so I have to find a fix..

    I've re-written my sprite manager several times now, assuming I'd made some error, but the problem keeps coming back at some other point no matter what methods i use to build the sprite patterns (games usually have 2-3 16x16's to make a game char) The games are arranged to minimise sprite flicker but if it does occur it alters priority to reduce the flicker..

     

    Its very frustrating, the only thing I can think of is if there is some area of ROM or RAM that I am not supposed to be accessing, though I see nothing in the docs that suggest that.

     

    So anyone know what is going on? I really want to get this game out on cart but until I can be sure it works on hardware I can' t release it.

    .

  3. Posted

    The only real advantage, is running in RAM allows you to use self modifying code which was useful in the early Z80 days on computers to save variable space and make some routines a little faster (direct load of a register is faster than a memory load) several clock cycles can be saved in loops, but with the CV having such a small amount of RAM and its video being tied to the TI chips access clock, there's not a lot to be gained from these kind of code gymnastics. But am sure someone will find a good reason to do it.

  4. Posted

     

    If you already have chosen efficient algorithms, and have some function called in an inner loop that has a big impact on the speed of your game, and a look at the compiler-generated code shows ineffciencies, and you are willing to really think about how to do the calculations fast in assembler, then assembler is the right tool for that function.

     

    Often, however, hand-written assembler would only be marginally faster than hand-written assembler code, and assembler code written without putting a lot of effort into making it very efficient might even be worse than compiler-generated code. And the sdcc compiler keeps improving. My games first written around 2006-2008 often had about a dozen functions written in assembler. When I now look at them again, many of them would be adequately handled by the compiler. I sometimes removed asm functions and went back to the C version, because the improvements in the compiler, with the C version now being as good or nearly as good as the asm version.

     

    There are some functions for which I noticed sdcc would generate rather bad code many years ago. I kept them around and used them as a benchmark while working on sdcc. Numbers that show how sdcc improved over time can be found at http://sdcc.sourceforge.net/mediawiki/index.php/Z80_code_size - even though the graphs are old).

     

    Philipp

    I would contest the statement that hand written assembler would only be marginally faster, but it really does depend on the code, and what you were trying to do.. I like C, I would really like to try it out on the CV soon. I'm very curious to see how well the SDCC works.

     

     

     

  5. Posted · Edited by BrianBeuken

     

    I guess C waste more memory than Assembler, and might be harder to control the stack?

    It does waste a lot of memory, but if the project does not need speed or memory its just far simpler and faster to express coding concepts in C.

    The stack isn't such a mystery, but yes you do need to take control of it as with all things in assembler, the coder rather than the compiler is in charge, with great power...etc..

  7. Posted

    Although C and other compilers do exist for CV it produces rather slow and bloated code. Originally all CV games were written in Z80 assembler, which is harder to code from scratch but over time you build up libraries of common routines and functions which with macros can result in reasonably fast coding.

    C will let you produce your code quicker, but CV is a fraction of the speed of the lowest level PC, so you should use the fastest most compact coding system possible, which is assembler.

    • Like 2

  9. Posted

    Hey all,

     

    I'm in the very final phases of my project, a port of a classic C64 game, which I will let my publisher tell you about when its ready, but I have been trying to touch up some of the artwork and finding it such a chore.

     

    I know we have the IPCH toolkit which is very useful on a character by character basis, but really quite limited when it comes to designing full screens or small sections of screen, sometimes you just want to draw a line from a to b on screen and let the internals take care of the chars

     

    I am painfully aware the 2 colour system on the TMS chips and the grouping of 8 chars per colour is problematic, but are there any art packages around, perhaps even on MSX that will let me draw screen based art, swapping to new character group and producing finally a character set and name table I can then use in games?

     

    If not, is this something others would find useful if I wrote one?

     

     

    cheers and watch this space for more details

  10. Posted · Edited by BrianBeuken

    not a single tile definition is updated while scrolling: all "rotated" tiles are already preloaded in vram (as said we use 1024 tiles)

    one step of scroll costs only 256+256 bytes to be updated in the pnt

    I just checked the uridum video and yes I do understand this concept for horizontal scrolling which is relatively simple but eats ROM (there's always a compromise(

    I'm really looking to find a way to do smooth 8 way scroll, all the examples quoted show only a vert or horizontal system, apart from the Burning rubber game which makes a damn good attempt at 8 way using simplified graphics to allow for reduction of work.

     

    Back in my Spectrum/Amstrad days we just used to dump recalculated screens to the visible screen but that's not practical on a low RAM, char map based screen.......creates an interesting and difficult proble

  11. Posted

    In "bitmap" mode tms9918a offers 3 banks of 256 tiles each

    Uridium relies on undocumented features of the vdp that, for two banks, allows to show two pages with 256 tiles each

    In this way you can show 512 per bank (1024 in total).

    The trick would work perfectly on Colecovision and on TI/99A

    The extra ram is needed to expand level data, and game logic, nothing to do with the scrolling which is perfectly doable

    ok but all this really allows you to do is create a (near) screen size character map that you can dump a bitmap to? I assume scrolling is then done by dumping to via x and y offsets into that buffer....but that's going to require a massive RAM buffer that's not available on the standard CV..hmmm

     

    So what are these undocumented features?

  12. Posted

    All of these entries are awesome. They encourage me to continue working on my current projects.

     

    Burn Rubber I know that does multiple directional smooth scrolling I think using tiles.

     

    Scrolling in 50/60 hz is pretty difficult. Replacing screen tiles for me is the quickest since the name table is 784 bytes. So 200-300 byte writes to vpd, so it'll complete updating the screen within 3 frames.

     

    I assume you are only writing to the VDP during the vblank refresh then?

    that's a good example of 8 ways scroll but yes it highlights how simple the graphics need to be so you're not redefining hundreds of chars.

  13. Posted

    hmmm yes very nicely done on vertical or horz scroll, but none of those techniques would allow for a true smooth 50hz 8 way scroll unless the graphics were incredibly simplified. Writing extensive bitmaps is extremely time costly and that's the principle needed to get uridium and other 8 way scrollys to work... does the SGM provide scrolling?

  15. Posted

     

    if you need 7 bit random numbers this code gives fairly uniform and uncorrelated random values

    
; Fast random number generator using the same method
; as the CDMA used in cellular telephones
;--------------------------------------------------------------------
; init random seed 

rand8_init:
	LD      HL,(JIFFY); on msx this is a time counter updated at any vblank interrupt, coleco has an equivalent
	SET		0,L
	LD      (randSeed),HL
	RET


; -------------------------------------------------------------------
; rand8
; -------------------------------------------------------------------
;
; choose a random number in the set [0,127] with uniform distribution
; return: A = random value

rand8:
	ld      hl,(randSeed)
	add     hl,hl
	sbc     a,a
	and     083h
	xor     l
	ld      l,a
	ld      (randSeed),hl
	ret

    neat and fast thanks...

  20. Posted

    Thanks Guys this is very helpful

     

    I'm currently not really using the BIOS beyond getting control pads and that Random number, R is of course usable but limited and I do occasionally need multiple random values in one routine making R less useful, I may just use my own random systems, but I do want to try and use the sound player for my music, since I don't have a decent music engine...I'll have to see, but the map is very helpful help me avoid crashing into the systems RAM.

     

    I appreciate the help.

     

    Brian

    • Like 2

  21. Posted · Edited by BrianBeuken

    The $73C8 location (RAND_NUM) two bytes should be initialized to $33 $00

     

    LD HL,$0033

    LD ($73C8),HL

     

    This is done by default if you use the Colecovision standard screen, but it's not done if you bypass the Colecovision screen.

     

    Once this is done you can get the random value from HL or A.

    I note that the system is using the upper part of its 1K to do system stuff, ie, $73C8 I thought that low part of RAM was being used so I have my ram starting at $7100.

     

    I think I may have that wrong now, can you give me some info on the system RAM usage?

     

    Brian

  23. Posted

    Hi guys

    can any one advise me on the use of the RAND_GEN routine, it does not seem to produce a result, returning 0 each time, I assume that is because it needs a random seed set somewhere but I can't locate where that seeding is done.

     

    in the meantime I'm using the R register but would very much like ot use the system routine RAND_GEN equ $1FFD

     

     

    thanks

     

    Brian

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...