kiwilove Posted May 19, 2014 Author Share Posted May 19, 2014 No - I don't expect Joint projects to easily come together - nor any team effort to, etc... Even teaming up a programmer with a graphics guy/gal - can be difficult in itself - but not impossible, I'll guess... Getting several programmers to work together, will no doubt be very difficult - maybe impossible... Someone has to be lead programmer - maybe lucky to have someone consulting.. wonder how Nintendo/etc go about it... The flip side is that I don't like seeing projects which could be that much better - with a little extra help... Or projects that fail in important areas --- like Crownload - really a fantastic effort - but still had a few rough edges to it, that could have been better? Control issues... Quote Link to comment Share on other sites More sharing options...
TMR Posted May 19, 2014 Share Posted May 19, 2014 Getting several programmers to work together, will no doubt be very difficult - maybe impossible... Someone has to be lead programmer - maybe lucky to have someone consulting.. wonder how Nintendo/etc go about it... By making it a nine to five job. All of the developers are in the same building and possibly the same office, one person is in charge and someone above them is paying everybody a wage (as well as covering power bills, air conditioning etc.) so they'll listen to that person. The model we use now is more like the "bedroom" coders of the 1980s and current indies, so there is usually one person (more often than not the programmer) acting as lead developer and everybody else is recruited after there's something running to entice them on board with. Which is better (and which produces the better games) is subject to debate, most of the games we love on the A8 and indeed other 8-bit computers come from the "indie" approach (even when things became more commercial at the end of the 1980s it was still the same model in use for a lot of professional developers, just beefed up with a project manager, maybe an office and for sure cross assembly), the popular titles for the Nintendo and Sega systems are products of the businesslike method. Getting the latter to work outside of a commercial environment is insanely difficult though, i've seen people try to get projects going with a team of half a dozen and they rarely get past the first hurdle - i've seen well-meaning big team projects crash and burn in a matter of weeks when nobody would make a call about which graphics mode to work in! 1 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted May 20, 2014 Share Posted May 20, 2014 For a "normal" game the indie approche is enough. At least for me as "my guys" live (almost) in the same town Our problem is more that these two are really busy in RL as they have other hobbies they value more However, you see the problem with (most) of these games. Either they are polished with simple (to program) game play or the other way around. For me that is understandable. If I have a game engine ready I want to get the thing out of the door and not code an additional year to polish it. I bet there are some A8 coders who wouldn't be able to code a (complex) game, but would be able to do the polishing (intro, inerlude screens, pause screens, ...). Or imagine someone would have had time/motivation to make a cooler level/enemy design for "Heli in the Caves"... 1 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted May 30, 2014 Share Posted May 30, 2014 I was asked to explain indexing files and indexing data in a file (xBios): We can index the files on the disk. we can " open " all interesting files "at once". The benefit is that the "open" indexed file is not related with searching the directory, the file is opened immediately. We can do this by function xBIOS_OPEN_FILE and store the file handle of the variables: xDAUX2 ( xBIOS + $3FD ) , xDAUX1 ( xBIOS + $3fe ) in any momnt we can open this file by function xBIOS_OPEN_DEFAULT_FILE and variable xFILE (xBIOS + $3EE) . OPEN_FILE functions can be replaced by xBIOS_FIND_FILE and take handle directly from the buffer ( save time ) We can also index the data in the file. when we are connect all data in one big file, and we want to have immediate access to them, we can do this: open file, move to the interesting point (i.e. xBIOS_SET_FILE_OFFSET) where interesting data begin (it does not have to be a block in a binary file) then grab the handle from xDAUX2, xDAUX1 and offset (variable xBUFFERO xBIOS+$3EB). If at any time a program want to have access to these data store file handle to xFILE var, do xBIOS_OPEN_DEFAULT_FILE and save offset to xBUFFERO. This operation is immediate - without directory searches or read file from start. also you can do xBIOS_LOAD_BINARY_FILE of any indexed point in file. variables and functions such as file offset now operate from this location in the file. general indexing files or data in the file is related with a single reading at the begining, later access to anywhere in the file is immediate (write 3 bytes), no longer open operation or directory search. indexing is safe, properly working with different densities, relocation buffer or library. xB v3 has a lot of new features (i.e. binary lib relocator...) Today I want to test this (with the older version not the V3 you appended here). To avoid mistakes which would cost em hours of debugging I want to clarify things. My file should be layouted like this: - general stuff - mainpart - INIAD (jump to start) - data level 1 - data level 2 ... 1.) At the start (after the loader jumped through INIAD) I store the file handle and the offset 2.) I do the open_default you explained and then xbios_load_data to load level 1 and store the offset in "off_lev2" for later use and so on for the other levels. sounds easy and logical. But now I have some question: 1.) the file handle is the same for teh whole file I assume so I have to store it only once? 2.) You wrote file handle is in XDAUX1+xDAUX2 is it really 16 bit or just 8 bit? As xFILE seems to be 8 bit 3.) The offset is in xBUFFER0 (8 bit) which sounds a bit small as I assume it is the number of bytes OTOH you wrote "(write 3 bytes)" which fits to the rest of your explanation. Could you maybe elaborate what "file handle" and "offset" are? For now I will implemented it as you described above, maybe it works without problems However, if it doesn't work I'd rather wait for a clarification instead of debugging Thank you very much in advance Quote Link to comment Share on other sites More sharing options...
Creature XL Posted May 30, 2014 Share Posted May 30, 2014 okay, I wait for a reply to my last message as it doesn't work I figured by now that xDAUX1/2 hold the sector number (as everyone with a bit of knowledge of SIO - not me - would have assumed). Before calling "open_default_file" I set xFILE. This value will however never be read (according to Altirra debugger) before the program crashes. The crash happens because a RTS leads to address 1. Probably this happen sin the part where values are pushed to the stack before JMPing thru INITAD which leads directly to a RTS. As said before, I stop here now instead of debugging further. Please note that I use the older xBIOS and not the V3 you posted here. I may try the V3 later. Quote Link to comment Share on other sites More sharing options...
Creature XL Posted May 30, 2014 Share Posted May 30, 2014 Sorry for the million posts I make today. But older posts can not be edited (at least not to my knowledge) I just made a quick test of the beta-V3 xbios.com and it gives me another error. It seems to use the SIOV routine. which is not available as I disable the OS ROM. With the older xbios.com this was no problem If a mod wants to join my last two posts with this one please go ahead Quote Link to comment Share on other sites More sharing options...
xxl Posted May 30, 2014 Share Posted May 30, 2014 (edited) opt h+l+ icl 'atarihw.ah' xBIOS equ $800 ; func xBIOS_LOAD_DATA equ xBIOS+$0c xBIOS_SET_LENGTH equ xBIOS+$1e xBIOS_SET_DEFAULT_DEVICE equ xBIOS+$2a xBIOS_OPEN_DEFAULT_FILE equ xBIOS+$3f ; var xIRQEN equ xBIOS+$3e8 xFILE equ xBIOS+$3ea xSPEED equ xBIOS+$3f0 xHSPEED equ xBIOS+$3f1 xBUFFERO equ xBIOS+$3f3 ; offset xDAUX2 equ xBIOS+$3fd ; hi xDAUX1 equ xBIOS+$3fe ; lo filo equ $00 fihi equ $03 fio equ $06 level equ $09 ekr equ $2000 chb equ $E000 l1_len equ $400 l2_len equ $300 l3_len equ $500 PUPBT1 equ $033D org PUPBT1 .byte c'xxl' ; make reset key work as reset org ekr .byte d'1,2,3 - change levels ' org $0c00 init1 jsr xBIOS_SET_DEFAULT_DEVICE ; no need AtariOS anymore lda xHSPEED ; set UltraSpeed if present bmi @+ sta xSPEED @ sei ldy #$00 sty dmactl sty nmien sty irqen sty xIRQEN lda #$fe sta portb sty $00 lda >chb sta $01 ldx #$03 @ inc portb lda ($00),y dec portb ; ROM OFF sta ($00),y iny bne @- inc $01 dex bpl @- lda <_dl sta DLISTL lda >_dl sta DLISTH lda >chb sta chbase lda #%00100001 sta dmactl ldy #$00 ; 01 level jsr get_file_index ldy #$01 ; 02 level jsr get_file_index ldy #$02 ; 03 level jsr get_file_index _loop jsr klawisze jmp _loop klawisze lda skstat and #%00000100 beq @+ _rts rts @ lda kbcode cmp #$1f ; 1 beq loadl1 cmp #$1e ; 2 beq loadl2 cmp #$1a ; 3 bne _rts loadl3 ldy #02 .byte { NPO $ffff } loadl2 ldy #01 .byte { NPO $ffff } loadl1 ldy #00 sty level lda filo,y sta xFILE lda fihi,y sta xFILE+1 jsr xBIOS_OPEN_DEFAULT_FILE ldy level lda fio,y sta xBUFFERO load_level ldx level_lenH,y lda level_lenl,y tay load_level_data jsr xBIOS_SET_LENGTH ldx >ekr+32 ldy <ekr+32 jmp xBIOS_LOAD_DATA get_file_index lda xDAUX1 sta filo,y lda xDAUX2 sta fihi,y lda xBUFFERO sta fio,y jmp load_level level_lenL .byte <l1_len,<l2_len,<l3_len level_lenH .byte >l1_len,>l2_len,>l3_len _dl :3 .byte $70 .byte $42,a(ekr) .byte $10 :4 .byte $02 .byte $41,a(_dl) ini init1 opt h- :l1_len/16 .byte d'LEVEL 1 ' :l2_len/16 .byte d'LEVEL 2 '* :l3_len/16 .byte d'LEVEL 3 LEVEL 3 ' first of all, use xB v3. I need change var location and/or func. order to force to use v3 > I just made a quick test of the beta-V3 xbios.com and it gives me another error. It seems to use the SIOV routine. which is not available as I disable the OS ROM. v3 could load from any device by default. if you want rom off: use jsr xBIOS_SET_DEFAULT_DEVICE and swith rom off or use xB header eg to reloc lib under OS or... wherewer you want. ok. best to explain on the example. === this can be useful func: xBIOS_RENAME equ xBIOS+$03 xBIOS_LOAD_FILE equ xBIOS+$06 xBIOS_OPEN_FILE equ xBIOS+$09 xBIOS_LOAD_DATA equ xBIOS+$0c xBIOS_WRITE_DATA equ xBIOS+$0f xBIOS_OPEN_CURRENT_DIR equ xBIOS+$12 xBIOS_GET_BYTE equ xBIOS+$15 xBIOS_PUT_BYTE equ xBIOS+$18 xBIOS_FLUSH_BUFFER equ xBIOS+$1b xBIOS_SET_LENGTH equ xBIOS+$1e xBIOS_SET_INIAD equ xBIOS+$21 xBIOS_SET_FILE_OFFSET equ xBIOS+$24 xBIOS_SET_RUNAD equ xBIOS+$27 xBIOS_SET_DEFAULT_DEVICE equ xBIOS+$2A xBIOS_CHANGE_DIR equ xBIOS+$2D xBIOS_LOAD_BINARY_FILE equ xBIOS+$30 xBIOS_OPEN_DEFAULT_DIR equ xBIOS+$33 xBIOS_SET_DEVICE equ xBIOS+$36 xBIOS_RELOCATE_BUFFER equ xBIOS+$39 xBIOS_LIST_DIR equ xBIOS+$3c xBIOS_OPEN_DEFAULT_FILE equ xBIOS+$3f xBIOS_READ_SECTOR equ xBIOS+$42 xBIOS_FIND equ xBIOS+$45 xBIOS_WRITE_SECTOR equ xBIOS_FLUSH_BUFFER after header by defult: .byte c'XAUTORUN ' ; autorun filename .byte >$0800 ; lib adr .byte >$0700 ; buffer adr .word INITAD ; INITAD .word RUNAD ; RUNAD .word AOSV ; I/O module .word AOSV_RELOC ; reloc proc for I/O module .byte $ff ; portb .byte $40 ; nmien .byte $c0 ; irqen .word xSIOV ; xSIOV .byte { RTS } ; dummy e.g. reloc for xSIOV but you can change it e.g: .byte c'MYFILE ' ; autorun filename .byte >$D800 ; lib adr .byte >$0000 ; buffer adr .word $0100 ; INITAD .word $FFFC ; RUNAD .word xSIOV ; I/O module .word DUMMY_RTS ; reloc proc for I/O module .byte $fe ; portb ROM OFF .byte $00 ; nmien .byte $00 ; irqen .word xSIOV ; xSIOV .byte { RTS } ; dummy e.g. reloc for xSIOV means xBIOS base is $D800 vars xIRQEN equ xBIOS+$3e8 xAUDCTL equ xBIOS+$3e9 xFILE equ xBIOS+$3ea xDIR equ xBIOS+$3ec xIOV equ xBIOS+$3ee xSPEED equ xBIOS+$3f0 xHSPEED equ xBIOS+$3f1 xBUFFERH equ xBIOS+$3f2 xBUFFERO equ xBIOS+$3f3 xSEGMENT equ xBIOS+$3f4 xNOTE equ xBIOS+$3f6 test.atr Edited May 30, 2014 by xxl 2 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted May 31, 2014 Share Posted May 31, 2014 (edited) @xxl: thank you very much for the quick help. The problem with V3 was the (missing) JSR to set_default_device. And with the variable definitions you posted my code seems to work. At least no crashes. Edited May 31, 2014 by Creature XL Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.