Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 09/11/20 in all areas

  1. 3 points
    Hi all, I've been wading through the dullest of dull bits of coding in the ongoing saga of my first ever game dev. I've just finished getting the player's stat bar "blobs" to function correctly. The routine reads the appropriate byte from the player's stats stored in one of the memory banks (health, gold, fatigue etc...) and draws the correct number of blobs, in the correct colour, in the correct place on screen, including splitting over 2 rows if necessary, including quarter / half / 3-quarter blobs. I wrote a simple version of the mod (%) function to do the fractional blobs which worked first time (OH JOY OF JOY!). Then wasted about 2 hours bashing my head against the desk trying to fix a bug which boiled down to me putting "0" where I should have put "#0". (NO JOY! REALLY NO JOY!) Unfortunately the game looks no different to how it did a month ago, but now I can get on with some more creative aspects of the game! Oh, and I've now got a working title for the game - "THE MYSTERY OF THE QUIET ISLE" which kinda sums it well I think Onwards and upwards!
  2. 3 points
    No. Assembly language is something you need to learn from other sources - like Jim Butterfields book for the C64 still one of the best books to read. Here are some links (depending on the language you speak/read) German: https://www.retro-programming.de/programming/assembler/ English: https://skilldrick.github.io/easy6502/ Here is Jim Butterfields book... http://www.1000bit.it/support/manuali/commodore/c64/ML_for_the_C64_and_Other_Commodore_Computers.pdf Also a good thing to understand the C64 book. It is actually everything that is referenced from the X16 dokumentation (e.g. BASIC, KERNAL calls etc.) http://www.zimmers.net/anonftp/pub/cbm/c64/manuals/C64_Programmers_Reference_Guide.pdf And this documentation to understand all the different inner workings of the Commodores ... very extensive and also quick reference. https://archive.org/details/Complete_Commodore_Inner_Space_Anthology_The_1985-03_Transactor_Publishing The Monitor is covered in this document: https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#machine-language-monitor
  3. 3 points
    Greetings Everyone, Danny from Missouri City, Texas here. To everyone involved in this endeavor, thank you so much. I downloaded your emulator and wrote my first BASIC code in 30 years! I can't wait to see how this develops and get one of these machines.
  4. 2 points
    It will be a 'one-off' but once done, I'll be happy to share the FPE and design details; In short, it's a MiniPet repackaged in a braked aluminum and sheet metal enclosure with an external 12" monitor (repurposed from a '82 Northstar Advantage; see below), optional external Petskey Keyboard, 10" LCD screen from China, internal SD, and a few surprises. Will not be battery powered (currently running off an 8 lb. linear differential power supply : ) Though depicted as a rounded corner traditional laptop (see FPD mock-up below), I plan on honoring the circa late 70's office furniture/vintage Pet look; call it, Tesla Cybertruck meets Atari Battlezone styling (said another way, I have a garage full of sheet metal brake, punch, shear tooling so outside of a wood enclosure, this is my only option - be prepared for something that looks more like a piece of aircraft than a computer) The good news is that I procured the monitor (below) and the LCD panel and controller for next to nothing (about $60 each) from eBay/Amazon. The bad news is that you get what you pay for and it looks about as good as what LCD technology offered in 1979-1982. Will post pics and info to this thread as I make progress. IMG_2052.HEIC IMG_2284.HEIC
  5. 2 points
    Bienvenue au Franco-Fun, un fin établissement situé un peu partout à la fois dans le cyberespace. Aux premier et deuxième étages, les vieux ordinateurs et autres merveilles de temps plus simples et révolus triomphent. Pour les curieux, le troisième et dernier étage offre une fenêtre directe sur les émotions d'un Windows. C'est pas vraiment palpitant, mais c'est l'étage où sont situés le bar et les bornes d'arcade donc... Bref, peu importe ou vous allez dans le Franco-Fun, c'est l'endroit idéal pour parler de tout, de rien et surtout de tout en français. On aime les vieux ordinateurs et on a hâte d'essayer le CommanderX16, mais aucun sujet ne devrait pas être abordé. Je commence: Ça fait un bout que je n'ai pas programmé en asm 6502 et je me souviens plus de rien. J'ai trouvé plusieurs excellents tutos sur le web en anglais, mais je me demandais si quelqu'un en connaît un en français pour plus facilement replonger dedans.
  6. 2 points
    Just a small clarification: When David mentions a Kickstarter he's using the word in the generic sense, meaning "crowdfunding". We're not yet decided what the home will be for the campaign. It may well be done within this website. Kickstarter is great for unknowns but The 8-Bit Guy brand carries some value and trust already that may make that unnecessary and help keep the end user price lower without Kickstarter's fees. More info when we have it!
  7. 1 point

    Version 0.6.0

    136 downloads

    This is a space invaders inspired game. Use the mouse to control the player ship. The shield segments can take 2 hits each. Now with 7 playable levels, only basic sound. Requires emulator R38! Roadmap: more diverse enemy formations enemy attack raids over the sides power ups (shields, double cannon, disruptors etc.) boss enemy joystick control music Different enemy sprites. done Sprite animations. done for player sprite and enemies fade in/out of palettes and backgrounds. done more levels with more backgrounds (all planets of the solar system), done sound effects basics done title screen
  8. 1 point
    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. 1 point
    It's not really RAM - it's I/O space. The system is set up so that when addresses within that 32 byte range are selected on the address bus, none of the internal memory chips respond. Instead, an expansion device is expected to set data on the data bus. So if you were going to use DMA to pre-load the system, the CPU would have to set one of those 32 addresses to particular value. The expansion device would be looking for that value at that address, then it would assert the DMA pin, and the CPU would shut down. Then the expansion device owns the bus while it does its thing. That thing can be: populating memory on the Commander, reading from the Commander memory, or even accessing the Commander's I/O devices (including VERA). So, as Bruce suggested, if you had an external processor on that bus, you could even take over the system completely and run it with something like a Z80 or 65816. This is how the CMD super CPU worked, as well as the CP/M cartridge and the 1750 Ram Expansion Unit. However... this requires a "smart" expansion cartridge, which doesn't make as much sense for simply distributing games or software. You'd be adding significantly to the cost to build a CPU onto the cart when all you really need is a PRG file that can be loaded from SD. If I recall, The way Lorin described it was that the startup script would be a bit like a DOS batch file. It would contain a series of BASIC statements that would be executed from a buffer. So a menu program would not actually BE the startup script. It would be called FROM the startup script, which might look something like this: POKE 0,1:LOAD "SERIALDRIVER.PRG",8,1 POKE 2,2 POKE 0,1:SYS $C000 RUN LOAD "MENU.PRG" RUN In this example, you'd be loading a resident routine into bank 1, setting a configuration variable (POKE 2,2) to tell the program which expansion port to use, and then starting the driver (SYS $C000). After that, the startup script would load the menu program into BASIC memory and launch it normally.
  10. 1 point
    Once a column is finished on the end, the invaders should move all the way across the field instead of keeping the same pattern of back and forth. Earth should be the last field instead of the first. Looking forward to further development.
  11. 1 point
  12. 1 point
    Nice, but could only get to level 2, all aliens dead but the stage did not end. Also. sometimes your shots does not hit most left side aliens. Otherwise nice wish it was harder Game Version: 0.3 Emu Version: Windows R38
  13. 1 point
    Thanks for the good advice. I predict two RAM banks are allocated for starmap data, which may need adjustment whenever the player's ship jumps to the next system. That's easily subsumed as shopkeeping during interstellar flight, and a (short) delay is a feature. In fact, a higher quality interstellar drive will reduce that delay. Anyway, that leaves at least 120 RAM banks for anything else. It really isn't Freelancer or Elite, although you've got me thinking. No no no no no SCOPE CREEP!!!! It's more like Star Trader, if you know about that, using Traveller to supplement the rules and data.
  14. 1 point
    I got the X16 one with MX Clear switches.
  15. 1 point
    This message will spoil your feeling of triumph, but it will help your code. The number four is a power-of-two. Therefore, you can use shifts to multiply and divide by that number: lsr a lsr a ; .A / 4 The remainder of that division is the two bits that were shifted out of the accumulator; in other words: and #(4 - 1) ; .A % 4 If you define the four "blob" characters next to each other in your font, then you can add the remainder number to your code number for the "empty/full" blob. You immediately will have the code number that will show the desired blob on the screen.
  16. 1 point
    I thought about getting a better workflow for programming X16 in assembler. There are several ways of writing code for X16 and to compile it. That is no issue. /EDIT: Already there in R38 2. Debugging within the emulator from outside with any IDE is currently not possible (not that I understand how it would be). Can we integrate a standard interface (like VICE does) that enables IDEs to control the build in monitors with breakpoints and stuff? That would be very possible with a monitor running within the emulator instead of running inside the virtual machine with a rom. The monitor we have is build into the x16 roms. But as Vice does it, the monitor is actually part of the emulator and can be controlled by the IDE from outside. What I am looking for is something CBMStudio or C64Studio does. If that interface is available, I will work together with the guy who wrote the C64Studio to integrate the X16emu ... then we have a full development IDE with Sprite Editor, Tilemap Editor, Color Editor and stuff including full assembler and debugger support .. I have a dream
  17. 1 point
    I checked C64studio but in the end I chose cc65 toolchain with Visual Studio Code as my IDE...
  18. 1 point
    Indeed, as far as getting the "big bang" that is key to getting visibility VIA Kickstarter, doing a CX16p/CX16c round in house and a CX16e round on Kickstarter would be an option to consider ... certainly the Kickstarter promo video with the CX16c in its case running a game and giving its price and then holding up the prototype CX16e "What we need your help for is to shrink it down to this". The latent demand of people waiting CX16e's using it as a pre-order would give the fast first day numbers that attract the attention of people browsing Kicksrter for cool things to share.
  19. 1 point
    But you can't make a clock to clock comparison, since the SuperCPU was still bottlenecked to a certain degree by the 1MHz system bus. A hypothetical CX16 DMA card can talk to the Vera registers at 8MHz, while the SuperCPU can only store to the RAM that the VIC can see at 1MHz. While designing the FPGA for the DMA, pick one with built in 16x16->32 multiply and include a scaled */ register setup for 16x16->32/16->16 operations. That avoids needing all of that tabled operation ROM. Then alternate between turn off layer 0 and build in layer 0 and turn off layer 1, build in layer 1 Switch layers in VRefresh it should certainly be flicker free. Whatever resolution / color depth cannot support two bitmapped And you get another level of effort reduction if you animate enemies and their cover onto sprites, since you can animate rising to fire or turning to call for help the same way with palette color games allowing the same animation to have enemies with different features and the higher priority sprite automatically masking whatever is being covered by the door frame, overturned table, etc, so that doesn't have to be blitted. Indeed, don't get trapped in bitmap-only assumptions. Plenty of dungeon crawlers will rely on the 1024 16x16 tiles available. 15 tiles spans a 320x240 top to bottom, one will be the wall to ceiling corner, the ones below it the wall at that distance, the ones above it the ceiling progressively closer as you go up the screen. In a normal level the ceiling might only have the occasional water stain, so most ceiling tiles in a row duplicated. Similar for a walls and doorways. Then you have a handful of distinctive features for the ceiling or the walls, and those need to have the current version, the next and the previous ... as they come closer maybe multiple tilemaps ... but as you advance or retreat, you only have to update one tile set or tile at a time after a POV move has moved, and you are always updating not-in-display tilemaps, so that is not limited to VBlank. That DOES NOT move you closer to executing a DOOM wad ... your POV needs to be a stable height above the immediate floor level for those to work ... and it constrains detail that isn't being added by terrain sprites ... but it seems like there's a lot of vertically scaled dungeon crawler game design to be explored in that space. Working on tiles in one layer while displaying the other will give much higher framerates than the equivalent bitmap approach.
  20. 1 point
    Concur. Since it's dedicated to the SD card slot rather than being a general purpose SPI channel, there's not a lot of payoff learning how to manage it at that level, and plenty of opportunity to trample on what the kernel is doing.
  21. 1 point
    The expansion port has all 16 address lines, the ready line and the line to tristate the 65c02 data and address ports, so technically it COULD, but it's not like the C64, automatically detected at power up and executed by the system start up routine ... detecting the system start up, and injecting code into the CX16 RAM to be executed would be entirely on the expansion card. So it couldn't be a passive ROM, but would have to be something like an AVR8 acting as a bootloader.
  22. 1 point
    I would recommend against using them yourself. The Kernal provides functions for you that takes care of all that for you. If you look at any Commodore programming guide, you will see how to use routines like SETLFS, SETNAM, and LOAD.
  23. 1 point
    I am certainly looking forward to buying the kit/DIP and discrete components/hacker version of this board.
  24. 1 point
    @SerErris I was impressed with C64studio as well. For my own Prog8 I'm also trying to make the whole process as smooth as possible so you just point it to a source file and it will compile it to assembly, run the assembler for you with the correct options, turning it into a .prg file and then launching that in the appropriate emulator executable. It loads and autostarts the program. From source code edit to running in the emulator in about 1 or 2 seconds on my machine. Works for C64 and CommanderX16. The above is hotkeyed in my IDE too. I'm using IntelliJ IDEA. It's a really nice workflow for me because I'm still developing the compiler itself as well, in the same IDE
  25. 1 point
    And if you need more VRAM for other things like sprites, you can decrease the color depth and take up less space with the buffers. I use the cc65 toolchain (C Compiler, Assembler, Linker, etc.) with Atom as my IDE for syncing with GitHub and getting syntax highlighting, etc.
  26. 1 point
    AND .. you can set both layers to Bitmap mode However that is most likely not what you want. What you want is: Lets assume you want a 320x200x4bpp bitmap with double buffer You start to use Layer0 for that. You set tile base to $04000 (if you do not need your text buffer, you can start at $00000) then build whatever you want in that screen ... Then you start building your next frame in area starting @$10000 .. after you are finished rendering it, you set the tilebase to $10000 Then you start to build in $04000 again ... flip back tilebase and so on. That is how you can do double buffering with VERA.
  27. 1 point
    BASIC's COLOR statement prints PetSCII color control codes to the screen. Kernal decodes them, and sets its private color variable. (Pssst, you might want to poke $376. But, you didn't hear it from me.)
  28. 1 point
    It does ... it sets this value in a BASIC variable that is used for all output. Not sure where it is - you can use the monitor and search $100-$3FF for any change after the color command Without now really knowing it I expect that the color command exactly creates this color byte and stores it in this variable to be used by any print char command later on to fill it into the screen ram. The VERA does not know anything about colors in that sense. It has the tilemap information (actually the Screen Ram is a tileset, where each tile contains a monochrome letter and the color byte points to palette entries). So the print char routines are not using any VERA technology. They just write the char to a certain position int screen ram and set the color information for the color byte. Really recommend you read the very good stuff on 8bitcoding.com ( no it is not from me )
  29. 1 point
    quick answer : You cannot read the VRAM with a monitor, nor with PEEK. The reason is, that the CPU cannot acces the VRAM at all. Instead you need to use the VERA registers to read from or write to the VRAM (VPOKE or VPEEK are implementing that).
  30. 1 point
    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!
  31. 1 point
    Nah, I'm not going to recreate Elite, the game. That would be way too much work. The 3d code is not a full 3d engine but just capable of showing one spinning object in the center of the screen I'm not going to expand that. I do want to add hidden line removal to it though and the other dozen or so ship models. As a separate project maybe to compile or convert that text-mode Elite trading program. That should be doable and will result in a fun little space trading game program (without fancy graphics though)
  32. 1 point
    You can load into VRAM by setting the A register to 2 or 3 when you call load. 0 for no verify, 1 for verify, 2 for loading into VRAM bank 0, 3 for loading into bank 1.
  33. 1 point
    Hm, interesting, didn't realize that the IRQ vector might be the same as on the C64. Thanks.
  34. 1 point
    Yay, the exported ship data works in the Commander X16 version! Attempt for the next version to implement hidden line removal in this version too.
  35. 1 point
    There is a vector located at $0314 that points to the interrupt routine (which is by default called at vertical blank every frame). Changing this vector to point to your own code will allow you to write a routine that runs at vertical blank. To make sure the original interrupt routine still runs, save the original value of the vector, and jump there at the end of your routine.
  36. 1 point
    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?
  37. 1 point
    That would be me. First, I love mechanical keyboards. Second, anything I can do that helps fund this project, even by a few dollars, is a worthwhile expenditure on my part. I'll be surprised if David and the rest of the team ever generate enough revenue off of this to compensate for the hours they've put into it. It's in the "labor of love" category, so if I can send a few bucks to help make that happen, it's money well spent, to me. And I have a cool keyboard I can use on my day-to-day computer, should I so choose!
  38. 1 point
    Please see FAQ [emoji4]
  39. 1 point
    And much slower . I write the color directly to VRam using the autoincrememt feature of Vera. But this is also a very good example more BASIC stile and good to understand. The issue with C64 Basic and also this version is that good to read is heavily inefficient (read slow). and to speed up on the initial diagram you should reduce maxdwell to 30. You will not be able to see any difference in that resolution ... I am not sure if anyone have done a c implementation. I next aim for a assembler version. The required math make my head spin already. We need long int mul/div ... phew
  40. 1 point
    Yeah don't worry too much about this. We haven't smoothed out final details yet. But if you look at the support forum here, it is set up in such way that it is community driven, whilst also accessible to the team.
  41. 1 point
    This may be the wrong place but Perifractic and the rest of the team will see it. I just watched David's Mini Pet video. Awesome as usual. He expressed concerns about people assembling a kit and it not working. I'm all in favor of selling the kits expressly WITHOUT a warranty. The person buying one should be capable of basic troubleshooting, just like David did. Maybe offer a warranty on the board BEFORE it gets soldered. Clearly if someone gets one with a scratch across a trace or merged traces, it could get replaced. That would just require an instruction to thoroughly inspect your board before starting assembly. Once assembly starts, its all theirs! I get wanting it to be a complete computer but I also get that just drives the price, and development time. Like many. I'll buy one no matter what. But there is a certain satisfaction assembling the whole thing and then using it. Heathkit stuff was great! Another consideration, which I'm sure you did, would be to release the boards and a parts list so some 'Beta' work could be done. Just like that Mini Pet kit. Having a few dozen users build and bench test them breadboard style could yield some interesting stuff. Either way, I can't wait to see one sitting on my desk I Scott
  42. 1 point
    That custom case looks so good... but I'm sure it's part of what's making the price so high. I know there are people who wanted a keyboard-computer style case for the X16 as well, but I agree with the decision to go with the Micro ATX if it keeps the cost down! That said, that Spectrum Next design looks so cool... I don't even have any Spectrum nostalgia, and I still want one.
×
×
  • Create New...

Important Information

Please review our Terms of Use