Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by geek504

  1. 1 hour ago, SerErris said:

    But to be honest, that is not really required for any games... 16bit math would be good enough. A math chip would "only" speed up the calculation. Esp. if you are talking about wireframe graphics like ELITE, the limited CPU is really slowing it down.

    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)


    • Like 2

  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. @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...

    • Like 1

  4. 8 hours ago, desertfish said:

    Turns out the prog8 compiled one is significantly faster (4x) even though it is using the same ROM routines as Basic does for the actual floating point calculations.

    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...

  5. 5 minutes ago, SerErris said:

    Look at the demo directories there are some Mandelbrot already. Two 320x240@256 versions ... it is running some 20-30 minutes for a full run.

    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
    120 CLS
    140 LINE 0, 0, NCOL + XOFFSET, 0, 16
    170 LINE 0, NROW + YOFFSET, 0, 0, 16
    250 HIGHDWELL = 0
    260 GAP = SIDE / NROW
    270 AC = AA
    290 AC = AC + GAP
    300 BC = BB
    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
    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 🙂

  6. 3 hours ago, SerErris said:

    So we even have a ELSE with multiple lines already in it. Yes it is a little bit different to write but it is not an issue and easy to understand after you  worked with it.

    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"!

  7. 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!



    "MANDELBROT.BAS" - Took forever to generate this 150px by 150px by 16 greyscale. 6502/200MHz please!


    • Like 8

  8. 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


    • Like 1

  9. 1 hour ago, SlithyMatt said:

    I'm teaching my 9-year-old daughter python, and it's going pretty well. Like BASIC, it has the benefit of an interactive shell, but is a better introduction to actual modern programming. At the end of the day, she has learned an actually useful language, and it wouldn't be as difficult to move on to other languages. And she can do it on pretty much any platform, so not tied to any hardware or OS.

    That being said, she sees what I'm doing with the X16 and she's really curious about 65C02 assembly. Can't wait till she's ready to dive into that!

    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... 🙂

    • Like 1

  10. 8 minutes ago, SerErris said:

    I would use actually anything then C64 for BASIC. The reason is, that they run out of ROM space and did not imlement a lot of basic things. So you have to use Peek and Poke with weird numbers and you will never get to it - actually very painful. 

    You cannot even plot a point or draw a line on the screen.

    To be honest everyone had a 6502 based computer (C64 for the most part) in the 80s, but C64 Basic was never good. Also the C64 architecture esp. the video modes are so weird, if you come from any other computer you will think that the developers were insane.


    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?

    • Like 2

  11. 6 minutes ago, Fnord42 said:

    There is, of course, the matter of acquiring the hardware...

    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"?

  12. 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?

    • Like 3

  13. 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!

    • Like 3
  • Create New...

Important Information

Please review our Terms of Use