Scott Robison

The link to the video in Japanese, or something I'm missing in the post prior to that? It's awesome to be enthusiastic and positive. It's also awesome to provide simple answers to questions rather than running around in circles referring people to past posts that are so verbose it is difficult to find details that are understandable to a native English speaker. I don't need a user guide. What would be nice is something comparable to David's videos about Commander x16 and/or the github repos and/or this website which are full of details. And many of these details were available before a prototype existed, so I refuse to accept that details can't be provided yet. Really I'm trying to figure out why you are here in the Commander x16 community, given your disdain for things like FPGA and manufactured through hole boards. I mean, I don't *mind* that you're here, but this just seems like an odd community to join to heavily promote something else that will be "beautiful" as compared to "ugly things" that you've described previously, of which the x16 seems to qualify. Look, I don't have enough hours in the day to do everything I want to do as it is. I'm always happy to learn about new things, but the information has to be at least somewhat readily available. The more I have to go digging for it, the less likely I am to bother. I've really tried to be polite despite what I perceive to be repeated ... insults? lashing out? ... against people who don't just immediately roll over and give you everything you want including unconditional support. I want to be positive and upbeat, but it is becoming more difficult. Just provide some simple sources of information that I can use to educate myself. Like what David did for the x16. I don't need a cheerleader to tell me what I should think about this nebulous project. If that's all that's available, fine, just tell me and I'll just leave the conversation for others to enjoy.

Is there a website or other place online where one can go to read more about this? I'm nice that you're enthusiastic, but at the moment I feel like all the claims being made have nothing to substantiate them. Which is fine, but I'd like to go do some reading of my own rather than just keep getting bits and pieces that lack detail and substance.

I wish I could get my students to be more proficient with the keyboard. I swear 75% of class time is spent with them using trackpads to move the cursor around, copy text, and paste it rather than just using good old arrow keys with shift, ^X, ^C, ^V. Sorry for the slightly off topic post. Venting complete. Resume with your normal meme activity.

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.

But seriously ... I meant it before when I said I wish the designer success. There is a long way between "providing an honest assessment" and "being an internet troll". I'm glad someone was able to, if not solve the problem, at least give you a suggestion on a potential route to follow. If successful, I don't know how the volume is going to work. Is the designer completely opposed to having PNG converted to a gerber file? I understand not wanting to do it directly, but would they be opposed to someone else taking the PNG and converting it to gerber for professional production? That feels like the best route forward that might satisfy the designer and still manage to acquire boards at a sufficiently inexpensive rate to make the platform viable for the impoverished people described. As for the inability to use paypal to buy a board, there are ways to pay other than paypal, of course. I have to believe that the cost of materials and chemicals to make a board from scratch will exceed the cost to buy a board from a supplier. Of course they wouldn't want to go to PCBWay or its competitors to buy a one off board as that's the most expensive way to do it. But if they're going to have to purchase other hardware to populate said board, I don't understand why they couldn't purchase a board from a similar supplier that can buy in bulk and pass along the savings. But I do understand tilting at windmills. I think we all do. We're not here because we think the Commander X16 is the best computer for all our needs. It is a hobby and we're willing to use retro technology because it scratches an itch. That's why I was surprised at earlier claims that we, of all people, were opposed to retro. I'm currently building an 8 bit CPU out of logic chips, breadboard, and wires. You don't get a lot more retro than that! I have a list of projects I want to work on when I can find the time. Things like writing an alternative IBM PC BIOS. I don't mean a BIOS for a modern board. I mean a literal IBM PC 5150 BIOS replacement that will provide a completely different interface to the hardware. I don't do it because there is money to be made or because it is modern. I do it because it is fun and would allow me to play a "what if" game with "what if Commodore had put together PC hardware, what would the system have looked like?" PC 5150 with monochrome would be effectively like a PET. Replace MDA with CGA and you've got an alternate universe take on a VIC 20. EGA gives you a C64-ish experience. Or creating alternative ROMs for C64 & C128 that make them feel more like an IBM PC. Frankensystems, if you will. Edit: I know Commodore much later sold PC compatible machines. I mean if they had originated the hardware platform.

You need to calm down. I said "no one here" not "no one anywhere". I never said "computer never existed before". No one here has made any such claim. You are inferring words that were not written or uttered. Maybe there is someone else here that can and will offer to help. Good for them if they do. My words were "it seems clear to me" ... that is not an absolute statement, it is a statement regarding what I can see and perceive. If it is such as easy, simple task, why hasn't anyone already offered to do it? I think that is the crux of the issue. Further: If you have to offer someone $2000 to make a board (I realize it was just an example), you are going to price the project right out of the target market ("The designer wants every student in every mud hut across the planet to be able to build and learn.") It probably won't cost $2000. Maybe $1000. Maybe $500. But the biggest problem (as I understand it) getting technology into those "mud huts" is the cost of the technology when those people are barely surviving with the amount of money they have available. The One Laptop Per Child project tried and failed 10 to 15 years ago to put inexpensive laptops in the hands of children. From the Wikipedia article: In many places in the world, a BOM of $40 to $50 is still going to be too expensive when their primary concerns are sufficient food and clean water. Very definitely drama. I intend to nominate you for an award! But are you wrong? I think you're wrong to call all the things you don't like garbage. There is a place for FPGA and modern design. And there is a place for more retro. This isn't an either or situation. When you talk in absolutes like this though, it's hard to believe it has a chance of succeeding, and by "succeeding" I mean "putting it in the hands of people to use rather than staying in the designers mind". I don't think the designer is wrong for wanting a specific outcome, but inflexibility is not going to help matters. Just my opinion, do with it what you will. As for the comment that came in while I was typing this: NO ONE IN THIS THREAD HAS SAID "IT LOOKS SO RETRO". You came looking for help. I think everyone here has offered what they can. Maybe someone else will come up with an idea that will help. Lashing out at people isn't going to get things built any faster, and no matter what hyperbole you use, it isn't likely to make someone come up with an idea that hasn't already been offered. Please don't put words in my mouth (or in my fingers, I guess, since I'm typing and not speaking aloud). I'm not cheering for the project to fail. I'm stating opinions, just like you. I just don't try to read between the lines of your comments and insert words that don't exist.

Well, I don't want to argue about it, as I know nothing about what it being attempted. I don't understand the mindset. But it seems clear to me that in the end, there is no one here that can help with PNG based PCB creation. There seem to be a lot of hills that this project wants to die on (no vectors PNG only, no purpose build PCB design software, no FPGA, no this, no that no the other). I wish whomever well and that they can realize their dream. I think putting artificial impediments in the way will do nothing but hurt the chances of said dream realization.

Note: There might be some savings to be had by converting some floating point values to variables, but at that point you have to ask yourself: Is it faster to lookup a variable by name or to convert a string to a float?

One last post, at least for now. Replaced all the 0 constants with a decimal point as I remembered they are slightly faster to process by BASIC. 0 TI=.:Y=.:X=.:I=.:V=.:U=.:N=.:M=.:R=.:Q=. 1 K=.000027/240:J=.000036/320:R=0.08784 2 FORV=.TO9:Q=-0.747345:FORU=.TO9:X=.:Y=.:M=.:N=. 3 FORI=.TO355: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=. 6 REM 7 Q=Q+J:NEXTU:R=R+K:NEXTV 8 PRINTTI/60 New time: 94.3833 seconds. Extended time estimate: 20.135 hours. Total time saved: 4.505 hours. 18.3% faster. Effectively unchanged.

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.

Note that line 130 only really needs to be computed when the value of V changes. Move line 130 to line 105 so it is only computed once per iteration of V. Also note that we square X & Y twice in line 170 and 180. We can make that faster if we only do it once per loop and reuse it as needed. Finally, line 180 computes a temporary value as T, then computes Y, then puts the temp value in X. Since we precomputed X^2 & Y^2, we can remove the need for a temporary by swapping 180 and 190. New code: 10 TI=0:Y=0:X=0:I=0:V=0:U=0:N=0:M=0:R=0:Q=0 100 FOR V=0 TO 9 105 R = V*0.000027/240+0.08784 110 FOR U=0 TO 9 120 Q = U*0.000036/320-0.747345 140 X = 0 150 Y = 0 160 FOR I=0 TO 355 165 M=X*X:N=Y*Y 170 IF M+N > 4 THEN GOTO 215 180 Y = 2*X*Y + R 190 X = M - N + Q 210 NEXT I 215 I = I - 100 216 IF I=256 THEN I=0 230 REM 240 NEXT U 260 NEXT V 270 PRINT TI/60 New time: 98.0333 seconds. Extended time estimate: 20.91 hours. Total time saved: 3.73 hours. 15.1% faster.

Next I did one thing that helped a little bit but not as much as I'd hoped, and another I should have done for the baseline. Here is the code: 10 TI=0:Y=0:X=0:I=0:V=0:U=0:R=0:Q=0:T=0 100 FOR V=0 TO 9 110 FOR U=0 TO 9 120 Q = U*0.000036/320-0.747345 130 R = V*0.000027/240+0.08784 140 X = 0 150 Y = 0 160 FOR I=0 TO 355 170 IF X*X+Y*Y > 4 THEN GOTO 215 180 T = X*X - Y*Y + Q 190 Y = 2*X*Y + R 200 X = T 210 NEXT I 215 I = I - 100 216 IF I=256 THEN I=0 230 REM 240 NEXT U 260 NEXT V 270 PRINT TI/60 I've replaced all two character variable names with single character names. They are faster to interpret, but not as much as I thought. I also removed lines 217 - 229 as they are not really part of the math, they are part of the plot. Removing them actually slowed things down slightly. New time: 107.1666 seconds. Extended time estimate: 22.86 hours. Total time saved: 1.78 hours. 7.2% faster.

The first change is just to a single line of code. Line 10 is replaced with: 10 TI=0:Y=0:X=0:I=0:PY=0:PX=0:YZ=0:XZ=0:XT=0 Every time a variable is accessed, BASIC has to look through the variable table for it. If it is the first variable, great! It is found quickly! If it is the 100th variable, it takes 100 times as long. Thus you want to create your variables in the order they will be most frequently accessed. In this case, X & Y are used the most, so they are created first (TI isn't a real variable). XZ, YZ, and ZT are used the least so we create them last. New time: 107.7666 seconds. Extended time estimate: 22.99 hours. Time saved: 1.65 hours. 6.7% faster.

I decided to create a different thread to document my approach to optimizing @SlithyMatt's BASIC code. Not because his code is bad. It is intended to teach. This is just a fun exercise to get a baseline calculation of the current code speed and what various optimizations do to enhance the performance. It will never run fast in BASIC! I've taken his code and removed the graphical parts of it. I think those parts are near optimal for BASIC. As he rightly observes, the math is what makes this program slow. So here is the baseline code I'm working with: 10 TI=0 100 FOR PY=0 TO 9 110 FOR PX=0 TO 9 120 XZ = PX*0.000036/320-0.747345 130 YZ = PY*0.000027/240+0.08784 140 X = 0 150 Y = 0 160 FOR I=0 TO 355 170 IF X*X+Y*Y > 4 THEN GOTO 215 180 XT = X*X - Y*Y + XZ 190 Y = 2*X*Y + YZ 200 X = XT 210 NEXT I 215 I = I - 100 216 IF I=256 THEN I=0 217 B = 0 218 OS = $4000 219 Y = PY 220 IF Y < 153 THEN GOTO 230 221 IF Y = 153 AND PX < 192 THEN GOTO 230 222 B = 1 223 OS = -192 224 Y = PY-153 230 REM 240 NEXT PX 260 NEXT PY 270 PRINT TI/60 Note that instead of a 320x240 plot, I'm restricting my calculations to the top left corner in a 10x10 area of the non-plot. While that might not be the slowest part of the program, it is "representative". In testing, it takes 115.5333 seconds to run. That is based on setting TI to 0 and then displaying TI/60 at the end. This generates the same number whether in warp mode or not, as the emulated computer still emulates the same system. 500% of real time speed means that I can run that 115.5333 second program in about 20 seconds of wall clock time, but jiffies pass at the same relative rate whether or not warp mode is enabled. So, baseline is 115.5333 seconds for a 10x10 area. If we extrapolate, there are 32x24 blocks that are 10x10, so 24.64 hours to calculate the information for an entire screen of 320x240. This is really close to what @SlithyMattreported, so it seems like a reasonable test case. Next post shortly...

I think I can judge it even in warp mode as long as I don't use wall clock time but use TI to report the number of jiffies a range of rows takes. I would clear TI to 0 after clearing the screen, then do a range of rows in the middle of the screen. Really, because the math is the intense part, removing the screen drawing completely would allow timing just the math code. That's the part in need of optimization (in as much as there is a "need" to do anything like this; there is far more utility to your easier to read and understand version than this, this is just "for fun".