Jump to content

geek504

Members
  • Content Count

    94
  • Joined

  • Last visited

Everything posted by geek504

  1. So, (monochrome SVGA) 800x600x1bpp = (800 pixels / 8 pixels-per-byte) * 600 lines = 60,000 bytes is possible? Also, (monochrome XGA) 1024x768x1bpp = 98,304 bytes? Also, (monochrome WXGA+) 1280x800x1bpp = 128,000 bytes?
  2. I had no idea you could create different screen resolutions other the ones provided by the SCREEN command, i.e. mode $80 320x200x256 and $81 640x480x16!
  3. I checked C64studio but in the end I chose cc65 toolchain with Visual Studio Code as my IDE...
  4. Gotcha! But I think we don't have enough VRAM for two 320x200x256 buffers... that's why SlithyMatt did 2 pages with 16 colors each. Edit: DOH! 4bpp = 16 colors... I should go get my coffee... I'm going to start some assembly coding and would like to ask: What workflow are you guys following? Which assembler? What steps to get the binary file inside the emulator? etc. I think my way is just too slow...
  5. Gotcha! I just did a cursory view at the SCREEN function and only saw this: Mode Description Comment $00 40x30 text $01 80x30 text (currently unsupported) $02 80x60 text $80 320x200@256c 40x25 text $81 640x400@16c (currently unsupported) I expected other "modes" to be already pre-defined and not for the user to set it up manually...
  6. Is this documented anywhere? I couldn't find any info on other graphics mode.
  7. Max speed as per spec is 14MHz, that's acceptable! FPGA implementation at 100MHz with pin-compatible format: (need some adjustments for X16's memory banks) http://www.e-basteln.de/computing/65f02/65f02/ I admit, I am suffering from feature-request syndrome! Coming from an Apple ][, the X16's 320x200x256 and 640x480x16 is nirvana in itself, the X16's 8MHz clock speed is way better than the ]['s 1MHz, and 2MB is more than I would need for my programming desires. So yeah, the X16 is just fine the way it is... let's make use of our creativity as you say! Our version of Wolf3D has to be creatively different!
  8. That’s why I am wanting the X16 to be at least 20MHz! We could do so much with that SuperCPUv2 Processor: WDC 65C816S Architecture: 8/16-bit Clock Speed: 20 MHz Opcodes: Documented 6510 opcodes only
  9. We might still have a chance on the X16! ... well, more than a chance... look at this! http://feed4gamers.com/game-news/144911/wolfenstein-3d-for-commodore-64-version-11.htm
  10. Proof-of-concept always in BASIC then slowly adding trig tables, SYS calls to assembly code, maybe a C version, then finally full assembly! Might as well ask now since I am trying to eliminate FLICKER: Is it possible to have two GRAPHICS pages (mode $80) and flip between them? (aka page-flipping). If not, is there any other graphics mode that does?
  11. That is something I am wondering too... which way is fastest to reset the GRAPHICS layer to black: 1. SCREEN $80 after setting palette color #1 to black; 2. RECT 0,0,319,199,16 <== can't use color #0 (transparent) so use the next available black; 3. Machine code to fill the screen memory with color #16.
  12. That's some serious stuff there Bruce! Thanks for the food for thought! I'm starting to brush up on 3D fundamentals... rotating 3D cube without hidden line removal... Wolf3D version 0.00001a LOL!
  13. This took me a while to figure out properly! Is my understanding below correct? 1. The TEXT layer is on TOP of the GRAPHICS layer. 2. So that TEXT "bg" color has to be set to "0" (transparent) so that the GRAPHICS layer is shown through. 3. SCREEN $80 is permanently defining color 1 (WHITE) as the background color for the GRAPHICS layer. (THIS IS KEY) 4. So in order to change the background color of the GRAPHICS layer, we need to manually alter the color 1 inside VERA's palette memory. 5. Changing the "bg" color of the TEXT layer (using COLOR command) other than "0" will hide the GRAPHICS layer. Thus LINE 50 in the original code is a mistake... it sets TEXT layer "bg" to the newly created "BLACK" color thus hiding the GRAPHICS layer. The line should read COLOR 6,0 and all is well. It seems a little inflexible to hardcode the GRAPHICS layer background color to "1". Perhaps allowing the user to set the color would be nice... it would avoid those ugly POKEs...
  14. Thanks Bruce for pointing out that Logo is also a proper programming language... I guess I never got to that part in grade school... BASIC was my defacto go to language at that time. Looking at the grammar style, it reminds me very much of my days using LISP to do some AI work in college... machine-learning using genetic algorithms. I remember that I did not enjoy LISP at all even though I dabbled with Clojure a few years ago. I will try showing the kids LOGO during one of my free presentation and see their reaction! At least its got graphics LOL!
  15. This also brings up another good point... we become slaves to the hardware, i.e. closed systems, proprietary hardware or software, many layers of security (e.g. TPM chip), kernel space vs user space, memory write protection, and being at the mercy of the OS. While all these things were created with security in mind, it is against the hacking spirit (old-school definition of hacker, i.e. MIT hackers during the 70s-80s) much like what Steve Wozniak wanted in his dream computer (Apple I/II)... direct memory access, and direct video ram access, many expansion slots, crashing the computer with memory corruption, writing tight code with prodigious assembly language skills, etc. We want a simple hardware that is entirely open and at the mercy of the hacker! The computer is our playground to explore and create havoc! Good havoc! And lastly... I would like to be able to fix my own computer when it blows a fuse or capacitor or what-not. I don't want to spend lots of money for a hardware and then the manufacturer will no longer fix "vintage" products. Just heat up my soldering iron and have a go! Hmm... a not-so-important issue is that I also want my computer to survive an EMF blast or some apocalyptic event that will take us back to the stone-age... I want my car with its old fashioned carburator, and my 65C02 computer running when that day comes... maybe I am asking for too much!
  16. Yes! Show me the code in these languages to plot a simple line across the screen and you'll see what I mean! (I guess Logo wins first place LOL!) Kids want to draw lines and circles... not add libraries and access methods with many arguments from complicated objects (that is, after setting the entire window, handles, viewport, etc. etc. etc.)!
  17. Java and C++ also has ugly boiler-plate code polluting the source (not to mention its weird syntax at times)... Microsoft fixed that with C#... that's a sweet elegant language!
  18. I teach Scratch, so that's where I am coming from. Like Matt said below: BASIC is able to teach simple programming concepts like functions, loops, variables, etc. which can then be taken and applied to other languages. I'm old school, so one of my goals is to (enventually) make my students comfortable with a text editor (Textedit or emacs) working on a terminal (DOS or bash) and not lean too much on an IDE, Debugger, or GUI. BASIC seemed like a good intermediate step between Scratch and Python. I do find C64 BASIC rudimentary but GW-BASIC (MS-DOS) is pretty advanced and modern. My other goal is to present Computer Science as very affordable without the need for fancy expensive laptops/desktops. A simple Raspberry Pi (and the like) would be enough to attain a high level of programming competency, either with modern GNU tools or running older systems via emulator... that is, until X16 comes out in embedded SoC format! Fun Fact: one of my students brought to class a Chromebook... Now that is a pickle... how do I tell the kid to go flash Debian Linux over that browser-only OS?!?
  19. I seriously thought about Logo too! I first learned BASIC on a TRS-80 and then when the school got brand new Apple ]['s they changed the class to Terrapin Logo. While pleasing to the eyes, it didn't do much else... I think today's kids can absorb Logo pretty fast and be bored in about a month or so...
  20. That would be cool BUT since there is no way to know what routines will be implemented by the user, the extended BASIC opcodes will be generic names, e.g. "USER1", "USER2", etc. Being generic and cryptic, it might as well be a SYS call to the machine code. The only imediate benefit I can see is perhaps the transfer of the resulting value (if it is a function) to a BASIC variable name.
  21. Ah, the KERNAL is a JUMP TABLE! The Macintosh 128K et al. has the same feature... allowing ROM bugs to be fixed in RAM and simply changing the value in the JUMP TABLE. It is a GOOD THING! Especially because I read the following: Someone might actually want to fix that in the ROM itself...
  22. Yeah, I grew up on the other side, the dark side known as Apple ][. The only Commodore I owned was an Amiga500. I'm not familiar with the term KERNAL but I assume it to be all the built-in ROM functions for all sort of stuff needed by the computer (e.g. input, output, clear screen, parser, commands, graphics, etc.) and accessible by the programmer using SYS (Apple ][ is CALL) and JSR (in assembly). I'm also assuming that X16 new commands were implemented in ROM as well using 6502 assembly. But when you say "pseudo", I'm not sure now. An 16-bit routines? I am aware of Steve Wozniak's SWEET16 implementation for the Apple ][ Integer ROM but that wasn't used much and didn't include math functions, just simple 16-bit LDA and STA. Why does X16 need a SWEET16 implementation? I have studied the entire Apple ROM disassembly... have yet to do the same with C64 when time is available. What I find the most peculiar and impressive is how C64 handles graphics and sprites with layers! That is amazing for an Apple ][ guy. I just watched yesterday The 8-Bit Guy's video on "Oldschool Graphics" and C64's use of COLOR CELLS versus Apple ]['s NTSC ARTIFACT COLORING. The most impressive of all is using the C64's CPU to change the color palette on each scanline of each color cell and achieve amazing pictures! (it's in Part 2 at 5:00)
  23. what's wrong with the good old ROM chips? Actually EEPROMs would be better.
  24. Not using SD card nor using VERA. Another independent circuit inserted into one of X16's slots as per spec below: Expansion Four expansion slots with access to CPU databus Each slot has its own 32-bytes of mapped RAM 8 general-purpose I/O lines available (user port)
  25. I was thinking to use an external card using Memory Map I/O akin to VERA chip with its own memory banks, i.e. the external 2MB RAM accessible by the 32 bytes I/O memory. The X16's RAM would be preserved. I guess we can forget about shaded 3D but maybe a fast game using wireframe instead? Last resort... 200MHz 65c02!
×
×
  • Create New...

Important Information

Please review our Terms of Use