Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by pirx

  1. The very detailed and in-depth research of POKEY by @pavros, continuation of work of beloved @analmux et al. has been just published on atarionline.pl (http://atarionline.pl/v01/index.php?subaction=showfull&id=1564612394&archive=&start_from=0&ucat=1&ct=nowinki). It was previously available in the latest issue of Atari Fan - twenty pages of dense wizardry, but now you can download the whole thing including demo programs and source code. Unfortunately the whole saga is in Polish language only, but we shall be able to help somehow if such a help is needed. The pack is here: http://atarionline.pl/pliki/pavros_znieksztalcenie_C.7z
  2. solid prod, kudos @Gibstov! very loose remarks as you are still developing the prod: - I was pressing START button like mad when in the menu screen to no avail as seeing "START" on screen made my neurons work this way. maybe you could check CONSOL there? - my pony does these jerky moves when colliding with background - as a retired games dev I understand this is a very difficult task to make collisions work nicely, but maybe a tweak here or there could help? - you need a tune and a splash screen, call for it and mega-helpful artists will help!
  3. Yes, it is the same in Atari Basic. Turbo Basic XL alleviates it by storing a table with line addresses.
  4. For SDX format do try Micro SpartaDOS by Jiri Bernasek and later our modest improvements.
  5. This ASM routine will not help as the problem is in the code around. You can check joystick and move x and y this way: s=stick(0) dx=(s=7)-(s=11) dy=(s=13)-(s=14) x=x+dx:y=y+dy It can be speeded up with s=stick(0)=x+(s=7)-(s=11):y=y+(s=13)-(s=14) For checking boundaries you can use a similar trick: x = x + scrX*((x=-1) - (x=scrX)) y = y + scrY*((y=-1) - (y=scrY)) Where scrX and scrY are dimensions of the screen. This wraps x and y around the screen, it can be modified to your needs. Definitely avoid GOSUBs as these are slow. Better have some fall through code or even inline if the subroutine is small.
  6. I've just got this idea, what about using Huffman coding where alphabet is build from 72-bit letters (9 bytes). If the entropy is low (and it is in SAP Type-R), this would yeld well over 9 times compression. Just looked at the real data - 89KiB SAP contains 790 symbols with this frequency: 1,8,8,8,1,6,6,8,1,8,8,6,8,1,2,142,69,59,142,47,3,24,20,22,7,2,3,25,12,12,12,60,5,28,28,29,3,10,22,14,13,18,2,2,2,1,1,1,1,1,5,14,32,11,17,5,48,8,22,16,20,1,44,5,22,17,17,3,27,8,12,9,7,2,1,1,2,8,8,14,5,4,3,20,8,7,9,1,6,6,8,6,6,6,3,6,6,3,3,7,1,9,6,7,6,3,3,6,1,11,4,2,6,10,5,6,5,4,2,2,1,1,4,5,2,1,1,6,19,15,18,14,11,14,3,15,18,14,7,3,14,47,64,38,138,142,17,88,72,56,4,18,296,47,29,22,16,68,48,38,23,4,12,16,12,8,4,6,4,4,2,5,2,3,4,2,20,40,20,16,10,16,11,9,52,3,13,31,31,24,12,2,64,28,23,24,14,10,14,10,5,2,2,4,20,13,11,123,19,12,16,12,12,12,18,12,12,12,12,34,12,12,6,13,12,6,12,12,12,12,16,14,11,11,6,12,6,3,39,9,6,9,6,6,6,9,6,6,3,9,12,85,35,12,12,6,18,12,17,12,12,12,18,12,12,12,2,6,9,7,6,61,1,8,6,9,6,6,6,9,6,6,6,6,16,6,6,3,2,6,6,3,6,6,6,6,14,10,1,5,1,6,9,6,62,7,6,7,6,6,6,9,6,6,6,6,18,6,6,3,2,6,6,6,6,6,6,9,6,6,6,1,8,2,3,6,2,6,11,5,8,6,9,6,6,6,9,6,6,1,1,1,1,2,7,4,1,1,2,1,1,1,1,1,1,1,8,6,4,2,1,1,1,2,2,2,2,1,1,1,1,4,32,84,4,4,51,8,32,83,5,2,5,57,6,16,22,2,4,1,2,59,1,2,8,6,4,4,8,6,8,8,4,6,4,4,8,4,10,9,4,3,2,2,4,3,4,4,2,3,2,2,4,2,5,4,2,3,2,4,3,4,4,10,1,11,11,11,1,5,108,66,52,48,90,97,92,78,71,92,90,103,15,74,66,7,26,70,101,54,50,20,2,4,10,14,8,8,6,4,6,4,2,2,4,6,4,2,4,2,2,4,5,5,4,2,17,37,21,16,6,4,1,5,4,4,4,6,4,2,4,3,1,4,2,10,14,8,8,14,12,17,12,9,8,12,8,1,7,8,1,5,10,14,8,8,4,3,4,15,10,8,8,1,4,6,4,4,4,4,8,4,4,2,5,13,17,13,12,8,22,6,24,60,88,47,43,29,29,31,24,3,10,13,12,10,6,9,22,14,10,3,15,13,15,12,6,5,3,1,14,17,19,13,9,1,9,5,3,4,1,5,4,4,4,4,1,4,4,5,4,4,2,15,35,52,28,24,42,28,3,39,28,18,6,22,25,26,16,23,3,16,13,17,23,18,5,14,11,7,16,6,4,6,4,2,4,4,4,2,2,4,2,2,6,3,6,6,6,10,1,3,7,13,10,3,12,10,5,3,15,12,18,12,6,6,12,15,10,3,12,10,5,3,1,1,1,1,1,1,1,1,1,4,9,15,7,7,1,7,6,1,7,6,1,1,10,15,10,10,6,4,1,1,1,2,2,1,1,1,1,1,2,30,5,3,7,5,71,6,6,7,7,1,8,1,9,6,6,11,2,5,2,6,1,1,2,1,3,3,1,10,10,1,1,2,1,2,4,3,2,2,2,2,1,2,3,2,2,2,1,2,2,3,2,1,1,1,1,2,2,1,2,2,1,1,1,1,1,1 a lot of singletons, unfortunately, but still looks promising. The only issue will be the large symbol table (do not remember the correct name). Another idea: split SAP-R to 9 streams, delta them (good especially for AUDCn) and huffman, reverse when playing. Will result in small symbol tables and quite large decompression routine :]
  7. Do you know of any streaming compression of a decent quality - would be perfect for SAP Type-R sounds.
  8. Yea, it works and even has got full ZX Spectrum emulator :] http://drac030.krap.pl/en-acc-pliki.php
  9. the question is can it be used for a demo effect? :]
  10. here's our max 720 kb copier (omc65/mac65 compatible listing), should be easy to get it work in higher densities. As far as I remember it supports max 256KiB RAM, also easy to add more. Very dirty code, but copied thousands of floppies ;] I could tidy it up a bit, convert to mads and translate polish labels if anyone's interested. MK720.zip
  11. my humble entry "Neverending Sorry". A classic theme with a neverending twist. How long can Falkor become? How our little basic will cope with all this body size and path memories? Only ten liners can tell. TBXL, extreem NEVEREND.BAS NEVEREND.LST neverending_sorry.src.txt
  12. Someone remembers, yay )) Now I could do the exact conversion of 2048, there's a lot of space left in these 10 lines
  13. Easy: https://github.com/ghostFaceKillah/expert
  14. Besides JS emulator we have everything to run modern dev pipeline :] https://operation8bit.wordpress.com/2018/10/29/devops-for-a-commodore-64/amp/
  15. In the late 80's we made a bookkeeping software for a local bookkeeper. One client per floppy. First they used standard Indus GT clones, later on moved to TOMS 720 when books started to exceed 180KiB. The whole thing was coded in assembler and was accessing floppies directly, no DOS, just reading/writing sectors, printing via MicroPrint, of course. It was blazing fast in comparison to standard PC-XT Clipper apps available at that time. The guy is long retired, contacted him to get a copy of the software, but he couldn't find anything
  16. Friends, the true issue is not really graphics, but the huge effort required to code all the game logic, unless it could be somehow ported from C64 by our porting wizards. It's the same story as with the Sam's Journey - a better game is feasible on our machines, but we have less manpower to spend ~10 man years building such a game. What I can see as doable is a (single) screen playable demo, same as with Prince of Persia (for which we do have neatly formatted source code and stuff). Full game - when we hit pensions (ha ha ha).
  17. looked at it at the time - tremendous effort to port, might be a bit easier to port it from C64, but not necessarily when C64 uses hi-res sprites and stuff.
  18. This is nice and I love Prodigy, so all good, I'd would follow the melody a tad closer to the original https://www.youtube.com/watch?v=FtJPXatTpqY
  19. phaeron rulz again with his beautiful code, it is so cool that I am pushing it now to my kindle and will read it instead of boooooring 12 rules for life and the brothers karamazov ))))))))))))) i love you avery. of course my tbxl proggies fail due to hardcoded memory usage, but of course i'll fix this. flappy 10 liner of mine might have problems 'coz atx has a tad less fre(e) mem than tbxl, not much but still.
  • Create New...