Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by geek504

  1. I was thinking exactly for 3D games (e.g. Wolfenstein 3D). With the asynchronous aspect you brought up, I believe that the best would then be the 16-bit look-up tables. It'll only be a matter of memory fetching the pre-computed answer from ROM akin to how VERA works. Look at the link: http://wilsonminesco.com/16bitMathTables/ It provides 6502 code implementation for the look-up table via BUS, SERIAL, PARALLEL, and MEMORY MAP I/O. file name table size comments SQUARE.HEX 256KB partly for multiplication. 32-bit output INVERT.HEX 256KB partly for division, to multiply by the inverse. 32-bit output. SIN.HEX 128KB sines, also for cosines and tangents ASIN.HEX 128KB arcsines, also for arccosines ATAN.HEX 64KB ends at 1st cell of LOG2.HEX (next) LOG2.HEX 128KB also for logarithms in other bases ALOG2.HEX 128KB also for antilogs in other bases LOG2-A.HEX 128KB logs of 1 to 1+65535/65536 (ie, 1.9999847), first range for LOG2(X+1) where X starts at 0 ALOG2-A.HEX 128KB antilogs of 0 to 65535/65536 (ie, .9999847), the first range for 2x-1 LOG2-B.HEX 128KB logs of 1 to 1+65535/1,048,576 (ie, 1.06249905), a 16x zoom-in range for LOG2(X+1) ALOG2-B.HEX 128KB antilogs of 0 to 65535/1,048,576 (ie, .06249905), a 16x zoom-in range for 2x-1 SQRT1.HEX 64KB square roots, 8-bit truncated output SQRT2.HEX 64KB square roots, 8-bit rounded output SQRT3.HEX 128KB square roots, 16-bit rounded output BITREV.HEX 128KB set of bit-reversing tables, up to 14-bit, particularly useful for FFTs BITREV15.HEX 128KB 15-bit bit-reversing table (not included in EPROM) MULT.HEX 128KB multiplication table like you had in 3rd grade, but up to 255x255 MathTbls.zip all the tables, zipped, including BITREV15.HEX which is not in the supplied EPROMs ROM0.HEX a single Intel Hex file for ROM0 as I plan to supply it (also available zipped) ROM1.HEX a single Intel Hex file for ROM1 as I plan to supply it (also available zipped)
  2. I had to look up what Kotlin was... looks a lot like Pascal (or Delphi). Did you have to re-implement a lexical analyzer in Kotlin or did you use an available library? Did you finish all the grammar for Prog8? In the mid-90s I did a SPARC assembly compiler using the traditional C tools, lex and yacc. It'll be interesting to dig up that old source code and re-implement for 65c02 and X16. It might just be a waste of time since cc65 already exists... and time is a rare commodity.
  3. Prog8 - that's a very interesting language you developed. What's the history of the language?
  4. @BruceMcF very refreshing history! I am happy for Commodore's insistence and have a useful extended floating point representation for the X16. I guess to have an external co-processor would make those ROM routines useless and that doesn't seem to be in the spirit of 8-bit computing... I guess having an external expansion card that functions as a co-processor or as look-up tables would very much be in the spirit of 8-bit hacking! Just food for thoughts...
  5. Prog8 - that's a very interesting language you developed. What's the history of the language? I can't see how one can make it faster other than perhaps write a fixed point scaled-integer math library (faster but less precision) OR ask for some sort of coprocessor chip (maybe inside VERA itself?) with various mathematical functions including vector math to allow for some cool 3D games! Actually I saw someone create a 16-bit LOOKUP table for the fixed point scaled-integer math for various math funtions and burned into 1Mx8 EPROM pairs. How cool would it be to have INSTANT math calculations on a "simple" 8-bit machine? Many geek points there... It's been a while and I didn't have time to do some manual readings BUT how many bits wide are C64/X16's math functions? I have been in 32-bit/64-bit land far too long...
  6. You used pure C64 BASIC right with all those POKE's I used the new X16 BASIC commands and is somewhat smaller: 20 SCREEN 128 30 MAXDWELL = 150 40 COLRS = 16 50 NROW = 150 60 NCOL = 150 70 YOFFSET = 1 80 XOFFSET = 1 90 INPUT "LOWER LEFTHAND CORNER, REAL PART"; AA 100 INPUT "LOWER LEFTHAND CORNER, IMAG. PART"; BB 110 INPUT "LENGTH OF SIDE"; SIDE 120 CLS 140 LINE 0, 0, NCOL + XOFFSET, 0, 16 150 LINE NCOL + XOFFSET, 0, NCOL + XOFFSET, NROW + YOFFSET, 16 160 LINE NCOL + XOFFSET, NROW + YOFFSET, 0, NROW + YOFFSET, 16 170 LINE 0, NROW + YOFFSET, 0, 0, 16 250 HIGHDWELL = 0 260 GAP = SIDE / NROW 270 AC = AA 280 FOR X = XOFFSET TO NROW - 1 + XOFFSET 290 AC = AC + GAP 300 BC = BB 310 FOR Y = YOFFSET TO NCOL - 1 + XOFFSET 320 BC = BC + GAP 330 AZ = 0 340 BZ = 0 350 CNT = 0 360 SZE = 0 370 IF (SZE < 4) AND (CNT < MAXDWELL) GOTO 380 375 GOTO 470 380 TEMP = AZ * AZ - BZ * BZ + AC 390 BZ = 2 * AZ * BZ + BC 400 AZ = TEMP 410 SZE = AZ * AZ + BZ * BZ 420 CNT = CNT + 1 425 GOTO 370 470 IF (CNT < MAXDWELL) AND (CNT > HIGHDWELL) THEN HIGHDWELL = CNT 480 IF CNT = MAXDWELL THEN PSET X, NROW - Y + 1, 16: GOTO 490 483 RE = CNT-INT(CNT/(COLRS-1))*(COLRS-1) 485 PSET X, NROW - Y + 1, RE + 1 + 16 490 NEXT Y 520 NEXT X 530 GET A$ : IF A$="" THEN GOTO 530 Your full screen Mandelbrot ran for 20-30 minutes running in BASIC? I was impatient and let it run overnight so I don't know how fast my code was even if a smaller 150x150. I will try cc65 and see much faster it becomes... unless you already did that
  7. Agreed. ELSE would be nice but not essential since it can be done using IF/THEN/GOTO. It's actually better not to have it for two reasons: 1. Use less ROM space; BUT if we have 128-512K ROM, why not? 2. Easier transition to assembly language programming which is really COMPARE/BRANCH/JUMP style. I only suggested for the sole purpose of teaching kids how to program and ELSE would be nice to have! Two-character variable names is tough to teach with... I'm thinking for teaching just programming maybe GW-BASIC is better, but if I wanted to teach hardware too, moving from GW-BASIC to C64 BASIC would be quite "painful"!
  8. Just fooling around with C64 BASIC and the new X16 BASIC commands! Code is too simple to share compared to some other games and demos you guys made! It's been a while trying to use variable names with only 2 unique characters! "PALETTE.BAS" "MANDELBROT.BAS" - Took forever to generate this 150px by 150px by 16 greyscale. 6502/200MHz please!
  9. I came here expecting to see some sort of smashing the stack for fun and profit... the classic buffer-overflow treatsie!
  10. LOCATE (GW-BASIC) or HTAB and VTAB (Applesoft BASIC) MOD (modulo) ELSE (would be nice)
  11. I was just giving feedback on improvements to BASIC since the dev people were asking LOCATE would be cool. MOD is another one: A-INT(A/B)*B Can't help shudder at the wasted CPU cycles...
  12. I read the KERNEL-BASIC documentation and have not found a command to be able to position the text cursor (same as LOCATE in MS-Basic or HTAB and VTAB on the Apple ][). C64 BASIC solves this problem with the never-ending POKE hacks: June 1992 issue of COMPUTE Magazine, Gazette edition! (page G-24, "Programmer's Page" column) POKE 211,C (moves cursor to specified Column, 0-79) POKE 214,R (moves cursor to specified Row, 0-24) BUT you must PRINT a carriage return after that, or the ($D1) and ($F3) pointers won't be changed. So, that's why you must make: POKE 214,(R-1)AND255:PRINT:POKE 211,C Yuck!
  13. You're a brave father! I only taught Python to my teenage son because he wanted to write games. Now he's learning C# with Unity. I'd think Python has a lot happening under the hood which may confuse a curious child... "Daddy, what does IMPORT TIME, IMPORT MATH, IMPORT OS, etc. do?" While it can be explained, it adds a whole new dimension to her learning. Having all the BASIC software and functions in ROM gives a certain comfort. Anything missing, just write it yourself! This LIBRARY making process will then help explain the IMPORT statements I'd love to watch you teach her LAMBDA functions...
  14. You said what I felt exactly. I always thought the Applesoft BASIC was better than C64 BASIC because doing graphics was easy: HGR, HPLOT, HCOLOR, etc. and kids NEED graphics! GW-BASIC is also pretty straightforward to use graphics and is very mature with lots of books available, BUT that's the "problem"... just BASIC and not too much hardware (emulation of course). X16 BASIC would allow me to teach BASIC, then 6502 Assembly, then talk about memory map, zero page, stack, soft switches, ROM, etc. Then the real Commander X16 will allow me to teach about the expansion slots and hardware hacking akin to the Raspberry Pi and Arduino. The plus being the child/teen can learn A LOT with an 8-bit machine without getting LOST with 64-bit wide registers, 16GB+ RAM memory space, complex OS APIs, etc. Learning 8-bit assembly within 64K memory space allows for efficient coding, something that's been lost today! Who remembers Michael Abrash's extremely tight x86 assembly code?
  15. Well... I'd think the students would run VICE emulator on their PC or run "Hand BASIC - CBM Flavor" on iOS iPad. As last resort, spend $35 on the amazing C64mini. Wouldn't the X16 emulator be better since it has better "hardware"?
  16. I teach a small group of children the programming language Scratch and ScratchJr. While it is easy, cute, and simple, I don't quite like it. I want to be able to teach the kids more about the computer architecture in general. The 6502 is a perfect choice for that IMHO. I can teach everything there is to know using an Apple ][, C64, or X16, but that means using BASIC. Question: Should I teach C64 BASIC, X16 BASIC (similar but better "hardware"), or GW-BASIC (A very solid BASIC using the awesome PC-BASIC emulator)? What are the pros and cons and what are your thoughts? Maybe even ditch BASIC altogether? Is it a waste of time to teach an "obsolete" language?
  17. I'm Ellery from Brazil and a longtime enthusiast for retrocomputing. In my collection I have: Apple ][+, Apple ][e, Apple ][ GS, Macintosh Plus, PowerMac G4 Quicksilver, PowerBook G4 Titanium, Intellivision, Colecovision, and the venerable Atari 2600 all in working conditions. I also used to have an Amiga 500, IBM XT, IBM AT, SPARCstation 4 and a NeXTstation "Whitebox". I cut my teeth with 6502 programming (BASIC and Assembly) during the 80s (Apple ][+), programming my own EPROMs, patiently going thru countless boot-tracing, and submitting my discoveries to COMPUTIST magazine. Those were the days... I eventually "graduated" to SPARC Assembly and C during college but never forgot my 8-bit days. Everytime I learn a new computer language, I write an Apple ][ emulator. So I have one in C, C++, Java, and Python and I'm currently working on a C# version. During my coding, I always wondered how I could improve the Apple ][, especially graphics, video, and memory capacity (and maybe dual-CPU?) while maintaining the simplicity of the 6502-based architecture. Fast-forward a few years I find this wonderful project! Not only is it what I dreamed of, it actually will be a REAL product. As a true die-hard Apple fanboy, I will admit today: Commodore 64 was superior to the Apple ][. But damn, that 1541 disk drive was pretty sad. Anyways, I look forward to having a Commander X16 soon! (I wouldn't mind a 6502 running at 100MHz or faster!) P.S. I'll start learning the C64 system ASAP and try to code a flashy demo!
  • Create New...

Important Information

Please review our Terms of Use