Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/18/21 in all areas

  1. I seen this and thought it was fitting as well. Also, I remember seeing the C5 in some magazine way back when, I can't recall what one, but I just remember thinking how awesome it was and wanting one so badly. People like Sir Clive Sinclair are the types of people I admire, true visionaries, often ahead of their time, who forever made their mark on the wonderful world of computing. What I often think of as the "golden age" of home computing. RIP Sir Clive Sinclair!
    2 points
  2. It is said that any computer can emulate any computer given enough time. So such a program could be as "simple" as implementing the emulator for the desired platform and running the code through. This is the biggest hammer approach to the problem, and probably the slowest, but should be able to perfectly emulate the C64 in all ways other than speed. Difficulties to overcome: BASIC dialects are different, but really x16 has a superset of C64 BASIC. Still, the addition of new statements and functions means that there can be perfectly valid programs on C64 that do not use PEEK or POKE that are invalid x16 programs. MX, MY, and MB could be variables in C64 BASIC but are integer functions in x16, just as one example. CPUs are different. Any ML program that uses an undocumented 6502 instruction will have to be adapted in some way to support the 65C02 which doesn't have undocumented instructions. Memory map is of course different. There is slightly less available RAM to BASIC programs. More when you consider banking but a BASIC program that just barely fit on a C64 might not fit on X16. Timing related issues. Not only might some things be too slow to replicate, some things might be way too fast given the faster CPU. Copy protection would require complex emulation given the differences between typical floppy drives and SDCARDS. Self modifying code is going to be a huge issue. In some ways this can be compared to a language compiler that allows you to select whether you want fast code or compact code. Such a converter might allow the user to indicate whether they want fast or accurate conversion.
    1 point
  3. Have you tried actually using the emulator debugger to look at what's in VRAM? Sounds like that could be helpful to you.
    1 point
  4. I think it's definitely possible to do a simple (well, "simple"), line-by-line converter that detects when you're writing to a C64-specific area and converts it to an equivalent X16 area. The same for converting graphics calls to equivalent VERA calls, etc. The only thing is, as people pointed out, in a lot of the more complex cases, such as demo scene stuff, that would probably end up being slow, since the various techniques to accomplish things on the C64 would not always be the best way to do things on the X16. So it's definitely possible, just that it would have a limitation of being slow in a lot of cases.
    1 point
  5. This has been updated to support commands\effects. I've added Slide Up\Down to the note, and Pitch Shift Up, as well as Silence which forces the volume to 0. Now the framework is done, its relatively easy to add something new. Working on the demo track, and will update the upload once done.
    1 point
  6. Wow that spring action is madness. I built two MX based keyboards. One with cheap-o black based on Kevin’s BOM for the PET replacement keyboard and one with Brown which is nice enough but ho-hum. Will live a little next time and go with that recommendation, thanks.
    1 point
  7. I totally forgot to respond to your question. Been a very long week. The most common consensus, and mine as well, is the MX Blue most closely compares to the Model M feel. Though it's important to note that a Model M and a modern MX Blue will still sound different, simply because they, and the boards themselves, are designed completely different, and thus resonate differently. The Model M has a deeper sound, it sounds "heavier", if that makes sense. Many modern switch keyboards sound more "hollow", it's a crisper sound. Both are "clicky", but the pitch is different. That buckling spring sound is just so unique, as is the sound of the key bottoming out. Completely different designs. Still, they feel very similar, and you can see why in the examples below, and can see where the clicky sound comes from and how they bottom out differently. Hope that helps!
    1 point
  8. I think it is possible in the future, just not probable that a code converter could be done. I believe it would take a ton of computing power to do so; I don't see it being on the fly on the X16 as there is only so much one can expect a 65C02 to be able to do. Looking at your example you've converted about 20 bytes of assembly into over 100 bytes - five times. I think memory space would quickly become an issue. While the example puts two characters on the screen, I don't think many existing C64 programs would take such an approach, rather subroutines would be involved. I guess that might reduce the memory required. Consider computer translation of human languages. One can convert some text word-for-word, but translating idioms really requires a grasp of the language and the intentions of the speaker/writer. With enough human power a program could be converted as you've proven. The question becomes how long it would take before a computer had enough power and insight to do the task? In that future, would "retro computing" be considered using a device manufactured last year?
    1 point
  9. No. The hardware is too different. The only stuff that will convert over with little or no change is text based stuff. It is possible to pseudo mimic the SID. Sent from my iPhone using Tapatalk
    1 point
  10. A 64x64x8bpp sprite takes 64x64 bytes of data, or 16 pages of VRAM. I think you're only giving it 8 pages.
    1 point
  11. Where did you find to follow it ? I can’t find anything.
    1 point
  12. I can't think of any PCB company that would take the job, just because things changed over the years. You are talking about a simple old-school process of making PCB that many did at home. It might not be a PCB company you are after. I think you have better chances of just finding some people who are ok to take any job that can be done with their bare hands. I will folow the project. I might be interested to build one unit for myself if you post enough information someday. I know there are many people who would like too.
    1 point
  13. Oh, I think I get it now. It's not about refusing to learn kicad - this designer friend of yours wants his boards done the old(er)-fashioned way as an aesthetic choice. And, that is a very visually appealing board design he has there. I've actually seen some of those acetone board-fab videos before on YouTube, so I know what you're talking about. The process looks quite difficult, but as you say, it's technically do-able (just not at large scales) if you can find someone willing. I hope the designer is able to find someone - maybe try contacting the people who made those YT videos; since they already have an interest in it and have already put time into getting the process down, then maybe they'll take an order, for the right price. Just a thought.
    1 point
  14. well here's something to throw stones at e.g. "Zomg it looks so retro" I think the current direction of the thread is the idea that a retro computer cannot be built, BECAUSE IT IS RETRO. It needs to be ugly, it needs to be modern and it needs to be gerber. None of those things will happen. It will be beautiful, it will be more advanced than any 8 bit computer before it, and it will not use gerber. Otherwise it shall indeed as Scott says 'die on a hill' for want of something there are video tutorials in abundance for. Here is a picture of the actual PCB in development at the moment to show the style. Tell me it can't be done.
    1 point
  15. Getting close to the end of the mechanical changes that can make it faster. First the latest code: 0 TI=0:Y=0:X=0:I=0:V=0:U=0:N=0:M=0:R=0:Q=0 1 K=0.000027/240:J=0.000036/320:R=0.08784 2 FORV=0TO9:Q=-0.747345:FORU=0TO9:X=0:Y=0:M=0:N=0 3 FORI=0TO355:IFM+N>4GOTO5 4 Y=2*X*Y+R:X=M-N+Q:M=X*X:N=Y*Y:NEXTI 5 I=I-100:IFI=256THENI=0 6 REM 7 Q=Q+J:NEXTU:R=R+K:NEXTV 8 PRINTTI/60 I've crunched it at this point removing all the extra space. I removed THEN from THEN GOTO as the extra keyword isn't needed. I also changed how X^2 & Y^2 are calculated. We know every time into the I loop that X & Y are 0, so X^2 & Y^2 are 0. Rather than multiplying 0*0 to get 0, we just initialize the values before the loop, and we only do the multiplication at the end of the I loop instead of at the beginning. Thus we save a couple multiplications for every pixel to be plotted. Also you'll note the line numbers are different. Shorter line numbers actually don't save any time except for when following a GOTO. It is faster to convert "5" to an integer than it is to convert "215" to an integer. Also, look at previous line 105 and 120. Every time through the loop we do a multiplication, a division, and an addition. But we know every time that the first value will be 0, so 0*anything/anything is still 0. Instead we just set the value of the variable to its known non-0 part before entering the loop, then at the end of each loop we add a linear offset. In other words, we are taking advantage of "y=mx+b". We compute m then just add it at the end of each loop iteration. I think that's all the changes I made this time. It took a bit longer to come up with enough that it felt worth updating. New time: 94.4166 seconds. Extended time estimate: 20.14 hours. Total time saved: 4.5 hours. 18.3% faster.
    1 point
  16. You're completely missing the point. The C&C hardware that makes PCBs today uses vector data files. There's no accepting of image files, because the systems don't support image files. The whole point of the Gerber file is that this is the format the hardware needs. That's not companies being "stubborn". That's simply the only way they can make a PCB. Honestly, if the guy can make a "no code computer", he can use KiCad. I don't get the stubbornness.
    1 point
  17. I've uploaded a new version of X16 Edit (0.4.0) incorporating some improvements of the program I've been working on during the summer and this autumn. It's nothing major, mostly fixing small things in the user interface not working perfectly
    1 point
  18. And of course, I would not be me, if I did not make a Double Petscii version of this picture of Sir Clive.
    1 point
  19. I know there are other threads about Cherry MX keyswitch types but speaking of the IBM, is there a 'color' switch that most closely resembles the classic? I remember the clang/click of the IBM keyboard and used to like it; I believe (but could be off) that they 3270 terminals had something like that and some keyclick audio tone to boot. That was college in the mid 80's for me; alot has happen since then so maybe I'm remembering it incorrectly.
    1 point
  20. It is a fully reprogrammable. It comes with an agent that allows you to define each key in four different layers, main keyboard or the three key cluster, so arrow keys are IJKL with a MOD layer shift state, and a MOUSE layer shift state even allows IJKL to be used in place of a mouse. Plus there is a FN layer. It is awesome. I haven't actually defined custom keys for the three key cluster as I've only had it for a few weeks. I can have multiple keyboard layouts too for custom app layouts, though I don't do that (yet).
    1 point
  21. Version 1.0.0

    42 downloads

    Got a day to kill with your X16? Run this BASIC program and generate this 256-color fractal plot. It's zoomed into a deep part of the Mandelbrot Set that is particularly pretty. This plot does up to 355 iterations and is within an area where all points require at least 100 iterations, so the whole 256-color palette is able to be represented, from white for 100 iterations to black for 355 iterations or more. For fastest results, run in "warp" mode with your emulator: x16emu -warp -bas x16-mandelbrot-vga-fancy.bas At 8Mhz, this will take literally all day, but if you have a beefy enough host for your emulator, it can be cranked out in a couple hours. Enjoy! From: https://github.com/SlithyMatt/multi-mandlebrot
    1 point
  22. The K70 TKL variant was on my shortlist, but unfortunateley at the time it wasn't availabe in a Swiss-German layout. It's media keys have a much better feel as the G915 ones.
    1 point
  23. I went ahead and bought a C256/U Rev B. + the SID / Ethernet add-on. Despite the base having a Gideon SID built in, I'm a sucker for SID and will pry SIDs out of my unused SX-64 and 128 then code a multi-SID tracker using 3 'SIDS' as a first project. Took a very long time to get through the web site / options, Discord threads, Twitter feeds, and many (but not all) of her marathon videos dating back to the earlier products. Stefany is a one-person wrecking-ball with undeniable experience when it comes to HW design, knowing how to get fab done, sourcing parts, etc. She only cares about two things... everything Foenix ("being able to produce cool f'ing sh* that will inspire people") and being able to pay rent a distant 2nd. Commentary about not worrying about where she will be in x years is hilarious and she has a number of really talented people delivering incremental piece-parts code etc. Mostly, she seems to really have great instincts about what not-to-include and why not to go down a particular path, this sometimes paralizes group-think and design by committee efforts. Similar to @John Chow Seymour, I'm still watching what is going on here, but Foenix has already shipped and is going to ship the latest efforts in the next few weeks; it's just too appealing to pass up so if you haven't been there (understandably, it takes a fair amount of time/effort to read it all), have a look at the C256 or the A* if that platform appeals. Based on the experience I'll probably be signing up for the Gen X. also once it gets closer. The 68K and enough resources to code in C "for fun and for profit" will be very appealing down the line.
    1 point
×
×
  • Create New...

Important Information

Please review our Terms of Use