Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/28/21 in all areas

  1. Hello, my name is Lotts. I'm from sunny Scotland! About a year ago I fell in love with fixing up ZX spectrums I bought cheap from Ebay and from there the hobby has just kind of grown. I'm not a great ASM coder (or even basic for that matter) but I want to learn and have some fun along the way! when I heard about a new system being developed similar to the C64/VIC-20 with minimal FPGA I thought it sounded to good to be true and wanted to explore it further. Some of the demos people have already released are amazing and I look forward to seeing more, and hopefully one day make some of my own. I wasn't actually born when the C64 (or ZX) was released and my first experience of it was the 30 in 1 TV console that Jeri Ellsworth designed, and I got hooked playing Uridium. My first computer was an Amiga 500, but prefer playing about with 8-bit machines mainly because A) I'm a bit of a noob and I find them easier to understand, and B) If I do break a ZX spectrum or clone machine, its easier to troubleshoot what the issue could be and Amiga parts are expensive now! anyway, wasn't really sure what to put here so I hope this is sufficient!
    3 points
  2. Mega65 has a repo started for this, and a defined process to ensure IP is not violated. I was excited to see this, even though it’s not a priority. An open source KERNAL ... seems to have a lot of appeal. https://github.com/MEGA65/open-roms
    2 points
  3. The exceptions are during initialization with the ACMD41 command. In other cases, the host is free to stop the clock and forget that the SD card is there at all, but ACMD41 starts the card power-up sequence and you must check back to see if that is finished at intervals of 50ms at most. You may stop the host clock during that interval, or leave it running, doesn't matter as long as it is getting polled every <= 50ms and the clock frequency, when the clock is on, is between 100 and 400 khz. I've spent several years as a silicon architecture engineer finding hardware bugs and driving RCA on them. With just the 6502 source code and an unclear description of SD card problem though, it's challenging to do any meaningful analysis. If we could get the dev team to sell a pre-release VERA board (and maybe release the RTL), I should be able to find the problem.
    2 points
  4. Hello Commandos, As you know the Mega 65 is another great project and based on Commodore's never-released C65 computer. Obviously the hardware is a bit different as it is FPGA-based, but I was curious, what do you prefer about the Commander X16 (chips aside) and its specifications and software, over the Mega 65's OS (if anything). What drew you here? Your friend in retro, Perifractic
    1 point
  5. Hi folks. I thought it might be fun to do a sort of "walk-through" post as I go about converting a short and simple BASIC program from another Commodore machine to the X16. Before I start, let me be really clear: This is going to be very entry level stuff, and probably over-explained. I'm trying to go for something that will be accessible to folks who are not experts but want to look into the X16. If people find this useful, I'll consider walking through a more difficult conversion. But the point of this initial write-up is to show how easy it is to convert quite a lot of the BASIC software out there, while also addressing some typical and important ways to optimize BASIC for performance. EDITED TO ADD: I also want to make a more general disclaimer. This entire exercise is occurring using the X16 emulator as a stand in for the platform. Also, the ROM and architecture are not yet completely final. Things could change. The emulator could be structured in such a way that it does not represent real world performance of what the X16 hardware would do. Don't expect the 'time' values from our optimizations to be exactly how this same BASIC program performs on the final X16 or any future emulator release. For this exercise I thought it would be fun to convert something from the Commodore Plus/4, which (like the X16) had some added bitmap graphics commands so you did not have to use pokes as on the C64. Browsing the ( very very good) 'Plus/4 World' web site, I saw this screenshot which seems like a nifty plotting routine that should work on the X16: So as a first step, lets fire up a Plus/4 emulator (VICE or PLUS4EMU are fine) and run the program on the original intended platform to make sure it works. Wait: What's this? Oh. OK, its apparently from the DANISH version of RUN magazine, circa 1984. My mediocre powers of deduction (i.e., simply seeing the characters '3D') were sufficient for me to ascertain that option 3 was the correct one, and I then went with what appeared to be the recommended parameters in a couple follow-up 'INPUTS' put up by the program after that. Viola! The Plus/4 emulator started plotting the same graphic depicted above. And..... wow is it SLOW on the Plus/4! I mean really, REALLY slow. As in just a few pixels plotted per second. After crying uncle and hitting RUNSTOP, I took a look at the program listing and found that only lines 0-9 and 1000 are used for the routines that plot the output in the first screenshot above. That's the part we'll convert to the X16, if we can. (The other parts of the original program are simple 2d coordinate plotting based on the same formula shown on the initial first screenshot). I deleted the program lines for the other routines and menus, added a 'GOTO' to flow things directly to the routine we're converting without having to pick it from the (now deleted) foreign language menu, and replaced a couple 'INPUT' statements asking for parameters with code that just sets those variables to constants using the recommended values from the original listing (see lines 3 and 4 below). Finally, I added commands to reset the system 'TIME$' (i.e, TI$) variable just before the start of the main output loops, and to print the elapsed time held in that variable at the end of the drawing. This will show us exactly how painful this was to run on the original Plus/4 hardware and, more importantly, it will greatly assist us in benchmarking our performance optimizations on the X16 version later. Here's what that BASIC listing for the Plus/4 version (after chopping it down to the essentials as described above) winds up looking like so far on the Plus/4 emulator: OK, lets just do a quick feasibility / sanity check at this point. In other words, CAN this be easily converted to the X16? Looking at the listing, I see the Plus4's 'DRAW' command (and its 'DRAW[ ] TO [ ]' variant) to make pixels and lines. We can do that on the X16 with 'PSET' and 'LINE.' I see the 'GRAPHIC' and 'SCNCLR' commands which set up and clear the Plus/4 bitmap screen, and we have 'SCREEN $80' to accomplish the same on the X16. Finally, I see the "COLOR" command used by the Plus/4 to set background, text, bitmap pixel 'color source', and border colors. Although the X16 handles bitmap colors differently, there's nothing so far that lacks directly parallel (or close enough) functionality on the X16. More important, of course, are the things we DON'T see in the listing above. I don't see any real headaches or show stoppers in the Plus/4 listing. There are no 'SYS' commands implying machine code or ROM routines; there's nothing poking a bunch of 'DATA' into memory or poking at platform specific (e.g., the TED chip on the Plus/4) hardware registers, either. There aren't graphics commands (such as circle or flood fill) that might be infeasible or slow/painful to implement on the X16 using just BASIC commands and without getting deep into some VERA /API expertise and lore. Looks doable. Just for fun, I turned on the turbo mode of the Plus/4 emulator and let the routine listed above proceed all the way to the end. Even with TURBO on I had time to go get a cup of coffee AND a refill. But in the end, I can report that: (a) the paring down of the program to the listing reflected above didn't break things on the Plus/4 emulator (I got the same output as the screenshot up top of this post); and, (b) from the printout of the 'TI$' variable at the end (showing hours, minutes, seconds, in the HHMMSS format), it appears it would take a genuine Plus/4 (or an emulator not running in TURBO mode) over TWO HOURS AND FORTY-TWO MINUTES to plot that screen! Yikes! Luckily, the X16 will be at least 8 times faster just on its CPU clock speed, and very likely even faster than that given the inherent speed of VERA and the skills of our X16 devs in implementing the X16 BASIC graphics command additions. Also, just glancing at the original Plus/4 listing, I already see a TON of optimizations we can do to speed up this program once we get it working on the X16. OK, next step before starting the process to adapt this little routine is to actually get the program onto the X16 emulator without having to type it all in. To do so, I first saved the program as listed above from the Plus/4 emulator in ".prg" format. Now we have a .PRG we know we can load into the X16 emulator! Well, that's it for this opening/introduction post. In the write ups / replies that follow, I will try to do the following things (in the following order): 1. Make it work; and 2. Make it fast. STAY TUNED!
    1 point
  6. OMG that brings back memories! I had picked up a couple of Next Generation Tricorder toys from KB Toys way back in the 90's to add to my collection of other Trek junk I didn't need. This one to be exact... Anyway, I got this bright idea I was going to make it look more like a TV prop than a toy. So I tore it apart, replaced all the lights with LED's and put some in spots where there should have been lights to begin with. I cut out all the fake buttons and put membrane buttons in their place, connected to a simple "beeper" circuit to make noise when pressed, and kept the original functions and sound effects in place. I also included a bright white LED on the top that could be used as a flashlight, all be it a dim one. As I was going through all my old stuff many years later, I found it and it's unaltered counterpart. I ended up taking a lot of the stuff to a big comic shop near St.Louis ta the time (can't remember the name of that place for nothing...), where I had bought and sold a lot of stuff in the past. The guy going through it all came across my "upgraded" Tricorder and fell in love with it. I joked and said "whoops", that one is mine", he immediately told me he would add an extra $50 for it. Of course, I responded "sold!" Seriously, I used to love doing that back then, making movie/TV style props. For some strange reason, it never once occurred to me to try and sell any of it.
    1 point
  7. You'll use it to learn. Anything else is just gravy.
    1 point
  8. Yes. However, implementing the Kernel interface would be even easier than producing a KERNAL rom image that is compatible with the bulk of C64 games and applications, so a project with the less ambitious goal could take what they have so far and likely complete it substantially faster.
    1 point
  9. The SPI flash is also used to configure the FPGA during reset, a sequence which is driven by either a hardware state machine or embedded microcontroller. If the CS pin for SPI flash goes low, that component must start responding or the FPGA will fail to configure itself properly. You could use an SR latch connected to the SD's CS (set) and reset (reset) to drive a multiplexer select, but that's adding even more external hardware. I'd consider repurposing the the debug UART as I2C and plug a board with an I2C to UART chip into it when a serial connection is needed for debugging (e.g. MaxLinear XR20M1280IL32-F). If I2C isn't fast enough and enough extra pins are available, that IC can also be configured to communicate over SPI.
    1 point
  10. OK, I have to guess... Yet another of my favorite games.
    1 point
  11. As someone put it in the comments, 4 and a half minutes of absolute proof the 80s were the best evah! Man, its my childhood and teen years in terms of the pop culture we all knew and loved boiled down and distilled into a hell of a potent nostalgia fix.
    1 point
  12. Its not an 80s 'meme,' but this video will make you grin from ear to ear if you're an 80s kid.
    1 point
  13. Proteus View File This is a single program listing that contains three different versions of the Proteus Demo from my thread in HOWTOs on converting and optimizing BASIC programs. Version .02 was from very early in the conversion/optimization process from that thread and, consequently, is quite slow. Its also got the original author's bad scaling coefficients, which make the output look a little gnarly. Version 1.0 was originally what I thought would be the 'fully optimized' version, with all sorts of things (documented in the thread) done to squeeze out better performance. And of course the scaling is fixed so the output looks better. This was supposed to be the end of the thread, except that... Version 2.0 takes advantage of something I noticed about the calculations, which led to the idea to have the program start off by precomputing a table that allows us to avoid having BASIC redundantly performing a bunch of the most expensive operations in the program. Even considering (and counting) the over minute-and-a-half it takes to initially compute the lookup table, the trick resulted in nearly halving the time to complete plotting the output compared to what was the previous fastest version. (Of course, I now wonder if some of the better math and coding gurus have been rolling their eyes all along, just wondering when, if ever, I might figure this part out...). Just RUN it and pick A, B or C from the menu. When its done plotting and puts up the elapsed time (its in HHMMSS format) you can press any key, and it will 'LIST' the program lines that correspond to the version that just completed plotting. I hope folks find it helpful having the three versions (and the howto thread) in terms of seeing how the thing evolved. You will notice that the more tweaking you do for speed, the more opaque and confusing the program becomes in terms of ever expecting someone with fresh eyes to try and see what the heck is going on. That 'early' version is included, in part, because its much easier to follow than the others. More info at the thread here: Submitter Snickers11001001 Submitted 08/27/21 Category Demos  
    1 point
  14. Already exists https://github.com/paulscottrobson/6502-basic No floats , largely because I don't like them but the hooks are all in there for it. It's designed to run in banked RAM, but doesn't have to. Haven't worked on it much recently. Whole pile of graphics sprite and sound functions, and a 65C02 assembler. From memory it's about 14k or something. https://github.com/paulscottrobson/6502-basic/blob/main/documents/Reference.pdf
    1 point
  15. In reality, my understanding of either is pretty superficial. I just figure there's always a more primitive technology that someone can pull out of their posterior because technology X is just too modern and difficult to understand.
    1 point
  16. I think your worries about the X8 diluting interest in the X16 are valid. I'd rather development be focused more on one product (the X16) rather than two. It would probably save you a bit of sanity anyways since money and time is tight.
    1 point
  17. Version 1.0.0

    89 downloads

    This demo features 3D rendering to a 256x240@8bpp surface with full transformation calculation, texture mapping and per-pixel depth buffering. The model is a decimated Spot test model with 512 vertices, 1020 triangles and a 256x64 texture. So, I wrote this just to get familiar with this system and figure out how to write and optimize a 3D math for it. Also, it would makes a nice reason for me to get up and do some coding streams, as shown here: Only runs on r39 since I can't find documents for older versions. There's still bunch of incorrect pixels due to depth buffer precision problems. Controls: A/D - Move camera left/right W/S - Move camera up/down Q/E - Move camera backward/forward (Z value should be an unsigned number but the UI only displays signed numbers) J/L - Rotate left/right (yaw) I/K - Rotate up/down (pitch) U/O - Tilt left/right (roll)
    1 point
  18. Here's my attempt to make side-by-side comparisons of the Commander X16, C256 Foenix, and Mega65: Commander X16 C256 Foenix Mega65 CPU WDC 65C02@8.192Mhz WDC 65816 @14.28 Mhz, Choice of extra CPU Options (256 GEN-X and Above, not relevant to this comparison) Custom FPGA Core based on the MOS Technology 4510@40 Mhz System RAM 560K Standard (48K Low RAM, 512K High RAM), Maximum of 2 MB available by populating all RAM sockets. Memory Map presumably can address up to 2,112K Total Up to 64MB Standard (System can address no more than 8 MB on 65816 power alone), 2 to 4 MB on Foenix U/U+. 512K Standard, Maximum of 8MB available by populating all memory slots, CPU possesses 28-bit address bus, capable of addressing up to 256MB GPU VERA, Separately Addressed Video RAM, 128K (Memory resources shared with PSG and PCM audio subsystems) (*) VICKY II/III, Separately Addressed Video RAM (4MB VICKY II, 8 MB VICKY III) VIC IV, Video RAM Space within larger System RAM can be remapped up to 3 MB, but is mapped to 384K by default in Mega65 Mode Resolution 320x240 (256 Colors Tile, 1024 Colors Bitmap), 320x480, 640x240 (64 Colors Tile, 256 Colors, Bitmap), 640x480 (16 Colors) 320x240, 256 Colors (65536, VICKY III) 400x300, 256 Colors (65536 VICKY III) 512x384, 256 Colors (65536, VICKY III) 640x480, 256 Colors 800x600, 256 Colors 1024x768, 236 Colors (VICKY III Only) All resolutions from VIC-20 and Commodore 64, Plus 360x288 (1024 Colors 256 Color Sprite CLUT) 400x300 640x400 720x576 800x600 (@) Sprites Maximum of 128 4-bit pixel (16 color) or 64 8-bit pixel (256 color) sprites. Sprite size programmable up to 64x64 pixels. Maximum of 32 sprites per scanline (16 8-bit pixel) Maximum of 64 32x32 pixel sprites. No Scanline Limits, bit width per pixel unknown Maximum of 2048 4 bit-per pixel sprites at stock memory configuration in Mega65 Mode. Sprite size programmable up to 32x32 pixels, but defaults to the stock Commodore 64 12x23. Maximum of 32,768 sprites when all memory slots are full Fields Maximum of Two Tile Fields, or one tile and one bitmap. Bitmap field lacks scrolling registers and must be scrolled through CPU power alone, but is split into quadrants each with a separate CLUT Maximum of 4 Tile Fields and 2 Bitmap Fields Choice of one Tile or Bitmap Field through conventional means, but judicious use of the Raster Rewrite Buffer can permit an arbitrary number of apparent scrolling fields. Other Features VideoDMA with Blitter Functions, Enhanced functionality and bandwidth in VICKY III DMAgic Video DMA+ Raster Rewrite Buffer effectively produce two different extra blitter methods at the same time Master Palette 4096, four bits each of RGB 16,777,216, eight bits each of RGB 8,338,608, color generation scheme unknown Sound Chips Yamaha YM2151+YM3012 DAC, 8 Channels FM Synthesis, 4 operators, 4 possible waveforms, 16 Channels Geometry Synthesis, 4 possible waveforms 1 channel 16-bit PCM synthesis, 48 KH maximum sample rate, 4K audio buffer Yamaha YM2151+YM3012 DAC Yamaha YM2612, 6 Channels 4 operator FM Synthesis Yamaha YMF262 (Several different modes of FM Synthesis + available 5-piece percussion set), Texas Instruments SN76489 (3 Channels general Geometry synthesis, 1 channel sawtooth and white noise) X2 Gideon SID Core (6 channels total geometry synthesis, multiple filter options)+ socket space on the motherboard for two physical SID replacement chips, Red Box (CD Quality) CODEC X4 SID Softcores (12 Sound Channels total), two based on the original Commodore 64 version, and two based on the Commodore 128/Later 64 version, four available sockets on the motherboard for physical SID replacement chips. Yamaha YMF278 (FM Sound Channels from YMF262+24 PCM Channels with 16-bit sampling@44KHz, based on the Yamaha YMW258-F/Sega Multi-PCM, Successor to the SegaPCM chip used in several Sega arcade games, used in the Yamaha SoundEdge PC Sound Card and the MSX Moonsound expansion cartridge) I/O VGA Output, A/V Multi-out, PS/2 Keyboard and Mouse, X2 7-pin Super NES controller jacks with headers for 2 more on the motherboard for an expansion backplane, Commodore-styled User Port (electrical profile based “mainly” on the Commodore 64/128 version), SD Card Slot, X4 expansion card slots, based on the Apple II Standard Varies by form factor. Mid-Tower and Full Tower Backplanes have: VGA Output, A/V Multi-out, Single-Link DVI Output, PS/2 Keyboard and Mouse, X4 Each Atari CX-9, 7 Pin NES, and 7 Pin Super NES controller jacks, SD Card Slot, X4-6 expansion card slots, physical, electrical, and protocol set profile currently unknown VGA Output, A/V Multi-out, SCART out, X2 Atari CX-9 joystick Jacks with two extra headers on the motherboard for an expansion backplane. X2 USB 1.2 Ports, Commodore User Port (Electrical Profile based on Commodore 64/128), Commodore 64 Cartridge Slot, Commodore Floppy and Datasette ports, X1 3.5” Floppy Disc (&) Form Factor Horizontal Upright, Separate keyboard optional. Smaller form factor models projected in the future Choice of Bare Motherboard, Small Form Factor(roughly Intel NUC/Mac Mini sized), Keyboard Console, Mid Tower, and Full Tower Keyboard Console OS Kernal + Commodore DOS, GEOS GUI Unknown OS for 65816. Motorola 680X0 processor upgrades offered with choice of EmuTOS+FreeMINT or Microware OS/9. x86 processor upgrades offered with DOSBox+ReactOS, ARM upgrades offered with choice of some sort of Linux distribution or OpenRISC (%) Kernal + Commodore DOS, GEOS GUI Built-in Language Microsoft BASIC 2.0+additional reserved words and syntax revisions to take advantage of the hardware Unknown BASIC interpreter Based on Commodore BASIC 2.0 Commodore BASIC 10.0, Mega65 BASIC 11 for Mega65 Mode. Also not that I did not list prices, because all price quotes are currently preliminary. Notes: *: VERA's 128K of Video RAM is the FPGA's fabric cache. Video Memory cannot be increased. @: the VIC III 1280x200 and 1280x400 resolution modes of the Commodore 65 are not supported due to a lack of availability of Commodore 65-spec CRT monitors, and the rarity and expense of 2560x1600 5:8 aspect fixed pixel monitors. &: Two Atari CX-9 Commodore 64 Mouse protocol/USB dongles allegedly packed in % Full Compatibility with classic MS-DOS software stack and classic Ad-Lib and SoundBlaster support not guaranteed with x86 processor options. Full compatibility with Atari TOS/MINT software stack with 680X0 CPU option not guaranteed. Full Compatibility with classic Acorn Archimedes/RISC PC software stack not guaranteed with ARM CPU option.
    1 point
  19. Excellent! Can't wait to see it. And... Just got it working! My "stock" A500 settings were not so stock after all. I dove WAY too far into this. I finally just deleted my A500 profile, ran the A500 Quickstart settings, bumped the CPU speed to 200% and drive speed to 800%, working like a charm! Sort of a "nuke" solution since I am not sure what I was overlooking, but it worked. So now I setup an "LCP" profile so I can play it with one click. I'm a happy man, with a happy LCP!
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use