Rybags Posted November 1, 2015 Share Posted November 1, 2015 You need to stay in front view and steer the crosshair in higher modes during warp, that's been the way always. In Novice you can select an alternate view/map and warp accurately so long as you don't inadvertantly steer it off course yourself. It's a worthwhile shortcut in Novice to save a few seconds (unsure if it affects energy use, might save a couple of units) by just leaving it on the Galactic Map. I would suggest speed clamping might be needed if warp becomes too fast, especially considering what a 7+ MHz slave processor might be able to accomplish. Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 1, 2015 Share Posted November 1, 2015 Well. That would happen if the difficulty is set higher than Novice, because then you need to use the front view to control the crosshairs manually when you are in hyperspace, Or you might end up in a different quadrant then you selected in the map, This normal behaviour in Star Raiders orginal Atari game. I was on Novice, so that behavior seems to have changed then? Quote Link to comment Share on other sites More sharing options...
a8isa1 Posted November 1, 2015 Share Posted November 1, 2015 (edited) I was on Novice, so that behavior seems to have changed then? In novice mode, forward view, you don't have to steer. but In galactic map mode your destination will be random. IIRC there was a cheat for the higher difficulty modes. I can't remember what it is. Long range scanner mode then warp? [EDIT - I thought this cheat existed but I was wrong] Edited November 1, 2015 by a8isa1 1 Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 1, 2015 Share Posted November 1, 2015 Ugh, I wen't back and played the cart version to compare behavior and the lag seems so much worse now. Quote Link to comment Share on other sites More sharing options...
potatohead Posted November 1, 2015 Share Posted November 1, 2015 I actually really like the lag. Technically, I've enjoyed reading all the discussion to improve this game in that respect. Fun stuff. But, that feel in battle makes it seem intense in a way similar to how DEFENDER feels when one manages to overdrive that one. Just an observation. Maybe all the extra time could be put to good use doing more stuff, so that when it does reach slow do1n, it is harder to do with more going on. Quote Link to comment Share on other sites More sharing options...
Grevle Posted November 1, 2015 Share Posted November 1, 2015 This version (Fastdiv 3) is amazingly fast, Even on PAL Atari it plays so smoothly, on NTSC Atari is almost insainly fast, To me this verison is so fast on Pal that maybe we could have a Pal version with edited colors so that the when playing on Pal Atari would have the same colors as the NTSC (Bluish color on the shield and so on). The feel when shooting Zylons are quite different in this version, feels more like proper dogfighting and quick reaction is needed to avoid when Zylons shooting at you. i Like it . 3 Quote Link to comment Share on other sites More sharing options...
ClausB Posted November 2, 2015 Share Posted November 2, 2015 Here's the fast divide I did 5 years ago. It uses fast and small reciprocal and quarter-square LUTs similar to my FAFMUL, except in binary instead of BCD, and signed and scaled fractional instead of unsigned integer. It also prescales the divisor and dividened for maximum resolution in the 8-bit quotient. The prescaler is a big unrolled shifting loop with extra optimizations to shift either left or right, whichever is shorter. It normalizes X so the hi bit is always 1 and then shifts Y and Z by the same amount. Then X goes through a reciprocal LUT before being multiplied by Y and Z. The quarter-square LUT method works because 4*a*b = (a+b)^2 - (a-b)^2. So the small 1-D LUT only stores squares, as opposed to a huge 2-D multiplication LUT. Also the constant multiplier of 80 is built into the quater-square LUTs. It's very fast but can jitter in the lo bit. CPU 6502 QSP1: EQU 0CBH QSP2: EQU 0CDH XL: EQU 0CBH XH: EQU 0CDH YL: EQU 0D4H YH: EQU 0D0H ZL: EQU 0D5H ZH: EQU 0D1H ORG TL-6 ; .OBJ file header DFB 0FFH,0FFH,<TL,>TL,<END,>END ORG 09000H TL: PLA ; BASIC arg stack for testing PLA STA XH PLA STA XL PLA STA YH PLA STA YL PLA STA ZH PLA STA ZL DIV: LDA #>QSQS ; Patched divide routine STA QSP1+1 LDA #>QSQD STA QSP2+1 ; QS LUT page addresses - QS tables are already scaled by 80 CLD LDA XH BNE SHH JMP SHL SHH: BMI SH0 ; Shift X until hi bit is 1 and then shift Y and Z by the same ASL XL ROL A BMI SH1 ASL XL ROL A BMI SH2 ASL XL ROL A BMI SH3 ASL XL ROL A BMI SH4 ASL XL ROL A BMI SH5 ASL XL ROL A BMI SH6 ASL XL ROL A BMI SH7 SH3: ASL YL ROL YH BCS OVF ASL ZL ROL ZH BCS OVF SH2: ASL YL ROL YH BCS OVF ASL ZL ROL ZH BCS OVF SH1: ASL YL ROL YH BCS OVF ASL ZL ROL ZH BCS OVF SH0: ASL XL ROL A TAY LDA RCP,Y ; Reciprocal of shifted X STA QSP1 EOR #0FFH TAY INY STY QSP2 ; Negate LDY YH LDA (QSP1),Y SEC SBC (QSP2),Y LSR A STA YL ; 80*Y/X = QS(Y+1/X)-QS(Y-1/X) LDY ZH LDA (QSP1),Y SEC SBC (QSP2),Y LSR A STA ZL ; 80*Z/X = QS(Z+1/X)-QS(Z-1/X) RTS SH4: LSR YH ROR YL LSR ZH ROR ZL SH5: LSR YH ROR YL LSR ZH ROR ZL SH6: LSR YH ROR YL LSR ZH ROR ZL SH7: LSR YH BNE OVF ROR YL LSR ZH BNE OVF ROR ZL ASL XL ROL A JMP DVL OVF: LDA #0FFH ; Overflow if Y or Z much more than X, or X=0 STA YL STA ZL RTS SHL: LDA YH BNE OVF LDA ZH BNE OVF LDA XL BEQ OVF BMI SH8 ASL A BMI SH9 ASL A BMI SHA ASL A BMI SHB ASL A BMI SHC ASL A BMI SHD ASL A BPL OVF SHE: ASL YL BCS OVF ASL ZL BCS OVF SHD: ASL YL BCS OVF ASL ZL BCS OVF SHC: ASL YL BCS OVF ASL ZL BCS OVF SHB: ASL YL BCS OVF ASL ZL BCS OVF SHA: ASL YL BCS OVF ASL ZL BCS OVF SH9: ASL YL BCS OVF ASL ZL BCS OVF SH8: ASL A DVL: TAY LDA RCP,Y ; Reciprocal of shifted X STA QSP1 EOR #0FFH TAY INY STY QSP2 ; Negate LDY YL LDA (QSP1),Y SEC SBC (QSP2),Y LSR A STA YL ; 80*Y/X = QS(Y+1/X)-QS(Y-1/X) LDY ZL LDA (QSP1),Y SEC SBC (QSP2),Y LSR A STA ZL ; 80*Z/X = QS(Z+1/X)-QS(Z-1/X) RTS DFB 0 ; Pad to page-align LUTs DWL 0,0,0,0,0,0 DWL 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 DWL 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 DWL 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 DWL 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 DWL 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 DWL 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 RCP: DFB 0FFH,0FEH,0FDH,0FCH,0FBH,0FAH,0F9H,0F8H,0F7H,0F6H,0F5H,0F5H,0F4H,0F3H,0F2H,0F1H DFB 0F0H,0EFH,0EEH,0EDH,0EDH,0ECH,0EBH,0EAH,0E9H,0E8H,0E8H,0E7H,0E6H,0E5H,0E4H,0E4H DFB 0E3H,0E2H,0E1H,0E0H,0E0H,0DFH,0DEH,0DDH,0DDH,0DCH,0DBH,0DAH,0DAH,0D9H,0D8H,0D8H DFB 0D7H,0D6H,0D5H,0D5H,0D4H,0D3H,0D3H,0D2H,0D1H,0D1H,0D0H,0CFH,0CFH,0CEH,0CDH,0CDH DFB 0CCH,0CBH,0CBH,0CAH,0CAH,0C9H,0C8H,0C8H,0C7H,0C7H,0C6H,0C5H,0C5H,0C4H,0C4H,0C3H DFB 0C2H,0C2H,0C1H,0C1H,0C0H,0C0H,0BFH,0BEH,0BEH,0BDH,0BDH,0BCH,0BCH,0BBH,0BBH,0BAH DFB 0BAH,0B9H,0B9H,0B8H,0B7H,0B7H,0B6H,0B6H,0B5H,0B5H,0B4H,0B4H,0B3H,0B3H,0B2H,0B2H DFB 0B1H,0B1H,0B1H,0B0H,0B0H,0AFH,0AFH,0AEH,0AEH,0ADH,0ADH,0ACH,0ACH,0ABH,0ABH,0ABH DFB 0AAH,0AAH,0A9H,0A9H,0A8H,0A8H,0A7H,0A7H,0A7H,0A6H,0A6H,0A5H,0A5H,0A5H,0A4H,0A4H DFB 0A3H,0A3H,0A3H,0A2H,0A2H,0A1H,0A1H,0A1H,0A0H,0A0H,09FH,09FH,09FH,09EH,09EH,09DH DFB 09DH,09DH,09CH,09CH,09CH,09BH,09BH,09AH,09AH,09AH,099H,099H,099H,098H,098H,098H DFB 097H,097H,097H,096H,096H,096H,095H,095H,094H,094H,094H,093H,093H,093H,092H,092H DFB 092H,092H,091H,091H,091H,090H,090H,090H,08FH,08FH,08FH,08EH,08EH,08EH,08DH,08DH DFB 08DH,08DH,08CH,08CH,08CH,08BH,08BH,08BH,08AH,08AH,08AH,08AH,089H,089H,089H,088H DFB 088H,088H,088H,087H,087H,087H,086H,086H,086H,086H,085H,085H,085H,085H,084H,084H DFB 084H,083H,083H,083H,083H,082H,082H,082H,082H,081H,081H,081H,081H,080H,080H,080H QSQD: DFB 050H,050H,04FH,04EH,04EH,04DH,04DH,04CH,04BH,04BH,04AH,04AH,049H,048H,048H,047H DFB 047H,046H,045H,045H,044H,044H,043H,043H,042H,041H,041H,040H,040H,03FH,03FH,03EH DFB 03DH,03DH,03CH,03CH,03BH,03BH,03AH,03AH,039H,039H,038H,038H,037H,037H,036H,036H DFB 035H,035H,034H,034H,033H,033H,032H,032H,031H,031H,030H,030H,02FH,02FH,02EH,02EH DFB 02DH,02DH,02CH,02CH,02BH,02BH,02AH,02AH,029H,029H,029H,028H,028H,027H,027H,026H DFB 026H,026H,025H,025H,024H,024H,023H,023H,023H,022H,022H,021H,021H,021H,020H,020H DFB 01FH,01FH,01FH,01EH,01EH,01DH,01DH,01DH,01CH,01CH,01CH,01BH,01BH,01AH,01AH,01AH DFB 019H,019H,019H,018H,018H,018H,017H,017H,017H,016H,016H,016H,015H,015H,015H,014H DFB 014H,014H,013H,013H,013H,013H,012H,012H,012H,011H,011H,011H,010H,010H,010H,010H DFB 00FH,00FH,00FH,00FH,00EH,00EH,00EH,00EH,00DH,00DH,00DH,00DH,00CH,00CH,00CH,00CH DFB 00BH,00BH,00BH,00BH,00AH,00AH,00AH,00AH,009H,009H,009H,009H,009H,008H,008H,008H DFB 008H,008H,007H,007H,007H,007H,007H,007H,006H,006H,006H,006H,006H,006H,005H,005H DFB 005H,005H,005H,005H,004H,004H,004H,004H,004H,004H,004H,003H,003H,003H,003H,003H DFB 003H,003H,003H,002H,002H,002H,002H,002H,002H,002H,002H,002H,002H,002H,001H,001H DFB 001H,001H,001H,001H,001H,001H,001H,001H,001H,001H,001H,001H,000H,000H,000H,000H DFB 000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H QSQS: DFB 000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H,000H DFB 000H,000H,000H,000H,000H,001H,001H,001H,001H,001H,001H,001H,001H,001H,001H,001H DFB 001H,001H,001H,002H,002H,002H,002H,002H,002H,002H,002H,002H,002H,002H,003H,003H DFB 003H,003H,003H,003H,003H,003H,004H,004H,004H,004H,004H,004H,004H,005H,005H,005H DFB 005H,005H,005H,006H,006H,006H,006H,006H,006H,007H,007H,007H,007H,007H,007H,008H DFB 008H,008H,008H,008H,009H,009H,009H,009H,009H,00AH,00AH,00AH,00AH,00BH,00BH,00BH DFB 00BH,00CH,00CH,00CH,00CH,00DH,00DH,00DH,00DH,00EH,00EH,00EH,00EH,00FH,00FH,00FH DFB 00FH,010H,010H,010H,010H,011H,011H,011H,012H,012H,012H,013H,013H,013H,013H,014H DFB 014H,014H,015H,015H,015H,016H,016H,016H,017H,017H,017H,018H,018H,018H,019H,019H DFB 019H,01AH,01AH,01AH,01BH,01BH,01CH,01CH,01CH,01DH,01DH,01DH,01EH,01EH,01FH,01FH DFB 01FH,020H,020H,021H,021H,021H,022H,022H,023H,023H,023H,024H,024H,025H,025H,026H DFB 026H,026H,027H,027H,028H,028H,029H,029H,029H,02AH,02AH,02BH,02BH,02CH,02CH,02DH DFB 02DH,02EH,02EH,02FH,02FH,030H,030H,031H,031H,032H,032H,033H,033H,034H,034H,035H DFB 035H,036H,036H,037H,037H,038H,038H,039H,039H,03AH,03AH,03BH,03BH,03CH,03CH,03DH DFB 03DH,03EH,03FH,03FH,040H,040H,041H,041H,042H,043H,043H,044H,044H,045H,045H,046H DFB 047H,047H,048H,048H,049H,04AH,04AH,04BH,04BH,04CH,04DH,04DH,04EH,04EH,04FH,050H DFB 050H,051H,052H,052H,053H,053H,054H,055H,055H,056H,057H,057H,058H,059H,059H,05AH DFB 05BH,05BH,05CH,05DH,05DH,05EH,05FH,05FH,060H,061H,061H,062H,063H,064H,064H,065H DFB 066H,066H,067H,068H,068H,069H,06AH,06BH,06BH,06CH,06DH,06EH,06EH,06FH,070H,071H DFB 071H,072H,073H,074H,074H,075H,076H,077H,077H,078H,079H,07AH,07AH,07BH,07CH,07DH DFB 07DH,07EH,07FH,080H,081H,081H,082H,083H,084H,085H,085H,086H,087H,088H,089H,08AH DFB 08AH,08BH,08CH,08DH,08EH,08FH,08FH,090H,091H,092H,093H,094H,094H,095H,096H,097H DFB 098H,099H,09AH,09AH,09BH,09CH,09DH,09EH,09FH,0A0H,0A1H,0A1H,0A2H,0A3H,0A4H,0A5H DFB 0A6H,0A7H,0A8H,0A9H,0AAH,0ABH,0ABH,0ACH,0ADH,0AEH,0AFH,0B0H,0B1H,0B2H,0B3H,0B4H DFB 0B5H,0B6H,0B7H,0B8H,0B8H,0B9H,0BAH,0BBH,0BCH,0BDH,0BEH,0BFH,0C0H,0C1H,0C2H,0C3H DFB 0C4H,0C5H,0C6H,0C7H,0C8H,0C9H,0CAH,0CBH,0CCH,0CDH,0CEH,0CFH,0D0H,0D1H,0D2H,0D3H DFB 0D4H,0D5H,0D6H,0D7H,0D8H,0D9H,0DAH,0DBH,0DCH,0DDH,0DEH,0DFH,0E0H,0E2H,0E3H,0E4H DFB 0E5H,0E6H,0E7H,0E8H,0E9H,0EAH,0EBH,0ECH,0EDH,0EEH,0EFH,0F1H,0F2H,0F3H,0F4H,0F5H DFB 0F6H,0F7H,0F8H,0F9H,0FAH,0FBH,0FDH,0FEH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH DFB 0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH DFB 0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH DFB 0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH,0FFH END: DFB 0FFH 4 Quote Link to comment Share on other sites More sharing options...
phaeron Posted November 3, 2015 Share Posted November 3, 2015 The algorithm I use in fastdiv3 is essentially the log() based algorithm proposed by others earlier in the thread, although with a lot of massaging: result = ptab[exp2(log2(y) - log2(x))] The logarithm is computed base 2 as a 16-bit result in 8.8 fixed point. The argument is first normalized via left shift until bit 16 is set (separately for each argument, not together). Since bit 16 is then known to be 1, it is discarded and bits 15-7 are used to look up in a table of log2(1 + x/256). The high byte is set based on the length of the left shift needed to normalize. That leaves how to do the normalization shift quickly. The amount of shift needed can be determined by looking up the high byte or low byte in a 256 byte table, depending on whether the high byte is zero. Shifting a bit at a time is slow, so shift tables are used instead. This requires a left shift on the high byte and a right shift on the low byte followed by a blend: norm_value = SHL(hi, shift) + SHR(lo, 8-shift). It is also possible to do this with one set of rotate left tables, rather than both left shift and right shift tables: norm_value = (ROL(hi,shift) AND mask) OR (ROL(lo,shift) AND NOT mask) Rotates are distributive with bitwise operations, however, and the blend can be rewritten to be two-arg friendly: norm_value = ROL(hi XOR ((hi XOR lo) AND rotated_mask), shift) This is then used as the argument for the log table lookup. Except... there's no need to have 8 rotate tables and one log table when we could just have 8 rotated log tables, giving the final algorithm for the low byte: log2_lo = rol_log_tab[shift][hi XOR ((hi XOR lo) AND rotated_mask)] The high byte of the log2 result is just computed from the amount of normalization shift required. An additional simplification is possible there, however. Since we are only going to use the difference between two logarithms, the log values can be biased by any amount and the result will be the same. We choose the high address byte of the rotate/log table as the log high byte, saving an instruction to look up the table address. The log2() core routine is therefore: ;input is in A:TEMP ;compute normalization shift tay ldx aligntab,y ;check if more than an 8 bit shift is required beq ilog_small stx rotptr ;merge low and high bytes eor temp and shr2tab-[>logtab8],x eor temp ;rotate it and look up log approximation tay lda $0100,y rotptr = *-1 ;result is in X:A 28 cycles for common case. Small arguments (<$0100) take a side branch not shown here that looks up using the low byte only and biases the high log byte by -8. This happens for about 10% of the cases. Zero is special cased off the small argument path by returning a large negative number (biased). The exp2() + ptab[] side is simpler: do a 16-bit subtraction of the log2 values, look up a table with the high byte, and look up in that table with the low byte. One table for the high byte lookup, 7 tables for regular low byte lookups, one underflow table, and one overflow table. Even here a simplification is possible, though: pre-negate the log2(x) value and use it to bias the table lookups for the log2(y) and log2(z) values. This requires extending the table by two additional pages and treating it as one long 2.8K table. The result (partially merged with the log2): ;merge low and high bytes eor temp and shr2tab-[>logtab8],x eor temp tay ;bias by -log2(x) high byte and look up table lda logbiastab,x ;!! - LSB modified by X-divisor ilog code logh_bias = *-2 sta rotptr ;look up log2(y) low byte ldx $0100,y rotptr0 = *-1 ;add -log2(x) low byte, do exp2() lookup and apply FOV (PTAB) scale lda $0100,x logl_bias = *-2 rotptr = *-1 log2() + exp2() combined is 40-42 cycles. log2(x) negation and self-modification takes 18 cycles. Thus, doing the y/x and z/x divides and the FOV/PTAB lookup takes about 140 cycles, using around 5K of tables. I've experimented with doing a direct lookup for computing log2() and it isn't much faster, due to the 6502's weakness in doing table lookups with 16-bit indices. The good news is that a full 16-bit table isn't required, since the high byte can be computed the same way as shown here, given careful rounding on the table. For values in the range $0000-0FFF this requires 4.25K of tables. 9 Quote Link to comment Share on other sites More sharing options...
ClausB Posted November 3, 2015 Share Posted November 3, 2015 Nicely done! (Aside from the hideous underscores and lower case mnemonics) Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 6, 2015 Share Posted November 6, 2015 Nicely done! (Aside from the hideous underscores and lower case mnemonics) I don't see that as hideous. I normally use lowercase. A few older assemblers I used didn't like underscores and I haven't used them since but I wouldn't call them hideous. Quote Link to comment Share on other sites More sharing options...
Savetz Posted November 30, 2015 Share Posted November 30, 2015 The team that converted the scanned Star Raiders source to text on github is done. Now, who can get it to compile? https://github.com/XioNYC/StarRaiders Quote Link to comment Share on other sites More sharing options...
luckybuck Posted November 30, 2015 Share Posted November 30, 2015 Hi Kevin! Will forward that to 2 Jedis here. Thank you so much. Maybe we will have others jobs of that impact in the near future... So, the multiplayer Star Raiders with up to 8 users and one Atari-Server is right around the corner? Quote Link to comment Share on other sites More sharing options...
Bryan Posted November 30, 2015 Share Posted November 30, 2015 I don't see that as hideous. I normally use lowercase. A few older assemblers I used didn't like underscores and I haven't used them since but I wouldn't call them hideous. I imagine it depends on what era you learned assembly in. I also find mnemonics easier to read in lower-case. I wonder if anyone has tried to make an assembly that uses icons to show functions rather than mnemonics... Quote Link to comment Share on other sites More sharing options...
JamesD Posted November 30, 2015 Share Posted November 30, 2015 The team that converted the scanned Star Raiders source to text on github is done. Now, who can get it to compile? https://github.com/XioNYC/StarRaiders And that will be different than the code that has already been posted? Quote Link to comment Share on other sites More sharing options...
Keatah Posted December 1, 2015 Share Posted December 1, 2015 Symbol table is missing. It's just a few pages so I don't see why it was left out. Give it to me and I'll type it in. 1 Quote Link to comment Share on other sites More sharing options...
1050 Posted December 5, 2015 Share Posted December 5, 2015 The team that converted the scanned Star Raiders source to text on github is done. Now, who can get it to compile?[/size] https://github.com/XioNYC/StarRaiders STAR.zip 1 Quote Link to comment Share on other sites More sharing options...
1050 Posted December 6, 2015 Share Posted December 6, 2015 More errata after second go around: pg 010 one extra tab on most lines pg 021 extra tab on line 33 pg 028 LDA for LDY on line 33 pg 036 HTARGT for HTRGT on line 58 instead of 56 in 1st errata pg 060 address correction on line 10 to be B138 pg 060 missing line inserted to be line 11: B13A 30 25 BMI CRATE3 To save time and effort for those in the project here is a zip of the corrected pages - these are only the ones that need correction and I believe I did it right but only when the git hub team says it's good is it good. One issue with these text files is that they are not exactly ascii as I understand it to be, they do not use #0d,#0a pair for end of line, carriage return as most ascii to atascii translators might be expecting - they use only #0a. How metapad doesn't stomp all over that I can't fathom except that I don't know enough about it. Not that I want to either. These text files also follow a rigid outline concerning tab use, I think I gathered it correctly but the team needs to weigh in on this issue. Hopefully someone fluent in GitHub can inform them where to find the corrected pages? I thought I was doing pretty good over there just to leave the errata sheet so I left before I could ruin that much. TIA for any assistance. Fixed Pages.zip Quote Link to comment Share on other sites More sharing options...
fujidude Posted December 6, 2015 Share Posted December 6, 2015 (edited) One issue with these text files is that they are not exactly ascii as I understand it to be, they do not use #0d,#0a pair for end of line, carriage return as most ascii to atascii translators might be expecting - they use only #0a. The single 0x0A for EOL is the 'nix (Unix, Linux, BSD, OS-X) way of doing it. DOS/Win uses a 0x0D 0x0A combo for EOL. The good news is that my program AAC (ASCII ATASCII Converter) can handle either style of EOL encoding to and from ATASCII. AAC is a command line driven program. There is a native version for the Atari8 (written in Action), and a Windows and 'nix version as well (written in Python). Oh and PS: Anyone interested in command line driven text file converters that convert between different ASCII types, search for the DOS2UNIX/UNIX2DOS and family of utilities. AAC only handles conversion between ATASCII and the DOS/Win and Unix style ASCII text files, so these other utilities are good for non ATASCII files. Edited December 6, 2015 by fujidude 1 Quote Link to comment Share on other sites More sharing options...
1050 Posted December 10, 2015 Share Posted December 10, 2015 (edited) Thanks fujidude, I was expecting the lesson to be painful, along the lines of a root canal which is why I alluded that I might be better off not knowing, but that one didn't hurt all and makes perfect sense all over. Nice to know the 'nix crowd has unity like that. I don't mean to beat this to death, but there are few more errors to report on. First my own, I neglected to include page 007 in the fixed pages zip and it's such a small fix I'll only report that it's missing. And then they will need further work too as below. The other two errors stem from the rigid tab rule on these files. Each line that is not a blank line must start with 13 character slots followed by one tab and that gets you to the column that would be column one when converted to source code. I'll call it 13+Tab error and pages 021 and 101 both have it on lines 33 and 9 respectively. These errors might be complexed within previous errata reports from me as a further complication but there it is. First time around I didn't understand why there were errors with page 021 and 101 but I was able to fix it within Mac/65 source code, same for second time around, but the third time was just too much so I dived in to find the why of it exactly. Turns out it wasn't as complicated as rocket surgery after all, but with all the other stuff going on in previous attempts, I couldn't make heads or tails of it so the errors and any hope for fix got lost in the shuffle. When you get this far then all the other errors that Mac/65 report on are the forward reference and really old school syntax issues. And these have nothing to do the source code project itself. And to that end here is a 'nix ascii version of the scanned pdf with all corrections applied and verified to compile to the byte when further adjusted for Mac/65 foibles and the mystery 07 byte at BFFB. combo.zip Jeeze - as individual pages too 1_thru_112.zip Edited December 10, 2015 by 1050 Quote Link to comment Share on other sites More sharing options...
fujidude Posted December 10, 2015 Share Posted December 10, 2015 Thanks fujidude, I was expecting the lesson to be painful, along the lines of a root canal which is why I alluded that I might be better off not knowing, but that one didn't hurt all and makes perfect sense all over. Nice to know the 'nix crowd has unity like that. No prob. Also, it's not just the 'nix crowd that has them. Those programs are also built for Windows. See this page. Quote Link to comment Share on other sites More sharing options...
thedoctor Posted January 9, 2016 Share Posted January 9, 2016 More optimizations... slightly faster divide, slightly faster rotation (EORing another value into RANDOM is pointless), faster motion routine, faster star brightness routine. I also extended the VCONL/VCONH tables to full pages to fix the intermittent crash. The problem occurs because the explosion routine presets HPOS/VPOS for the new explosion particles, which results in a weird grid pattern for the first frame. STVPOS is bypassed when VPOS is set, so the vertical positions are not clipped and can wrap. The out of bounds VPOS values are now clamped. The game can now hold 30 fps during an explosion, but it'll be hard to get it to 60 fps locked. The divide can possibly be sped up a bit more by adding direct tables for the very common $0000-0FFF range, and it looks like the star store/clear routines could be sped up by adding LMS lines to the display list so no mode line crosses a page boundary. The rotation routines, however, are going to be hard to speed up more as there's only so fast that four shear matrices can be applied to 47 points every tick. Hyperwarp is just barely short of 60 fps because of the extra overhead of all of the new stars that it generates, but arguably that is already running too fast as it is. One other thing that's apparent is that the constant use of RANDOM everywhere would complicate hoisting Star Raiders into Veronica. A possible approach would be to have the 6502 generate a new page of random numbers every frame, since it's wouldn't have much else to do. Uh, mind being a little bit more specific? I don't see anything wrong myself, although on higher difficulties it can be hard to stay on target and avoid miswarping. Hi, I am sort of new to this whole thing. I love Star Raiders and played the heck out of it in the 80's and 90's. I am really interested in this version with the faster explosions. But, I do not know how to make a version that will run in Altirra. Can anyone help me out? Thank you so very much! Quote Link to comment Share on other sites More sharing options...
phaeron Posted January 10, 2016 Share Posted January 10, 2016 I am sort of new to this whole thing. I love Star Raiders and played the heck out of it in the 80's and 90's. I am really interested in this version with the faster explosions. But, I do not know how to make a version that will run in Altirra. Can anyone help me out? Just make sure BASIC is disabled and then boot the .obx file. Quote Link to comment Share on other sites More sharing options...
thedoctor Posted January 10, 2016 Share Posted January 10, 2016 Just make sure BASIC is disabled and then boot the .obx file. Wow, thanks! That was easy! And wow, the game plays so much better! Thank you to phaeron! Quote Link to comment Share on other sites More sharing options...
thedoctor Posted January 11, 2016 Share Posted January 11, 2016 Hyperspace does seem a bit more sensitive to me. Or is it just me? You have to be more precise to get in the intended sector. Quote Link to comment Share on other sites More sharing options...
kiwilove Posted January 11, 2016 Share Posted January 11, 2016 Hi, I am sort of new to this whole thing. I love Star Raiders and played the heck out of it in the 80's and 90's. I am really interested in this version with the faster explosions. But, I do not know how to make a version that will run in Altirra. Can anyone help me out? Thank you so very much! I would like a Star Raiders in which the shield on - is the standard black background working in place - Green could be the text window, instead of blue? to indicate shields are on. I do love the feeling of travelling through deep space and would let the game run in this mode, in a darkened room. I am not at the Commander skill level to be able to play the game with no shields. Would love the other enhancements too - faster explosions, etc? Harvey Quote Link to comment Share on other sites More sharing options...
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.