JamesD

I'm pretty much regurgitating his argument. My argument is that it's his project, so he can do whatever he wants. If you don't like it, don't buy it. Since you know so much, make your own. If your's is better, maybe more people will buy it.

Another day, another game launcher Get Grand Theft Auto: San Andreas free for a limited time when you download rockstar games launcher https://www.gamespot.com/articles/rockstar-games-pc-launcher-comes-with-a-free-game/

Today is the last day for free Conarium, the next Epic Games free game is up tomorrow.

And that somehow makes it wrong to play it safe?

I know he was trying to avoid using FPGAs except for the video chip. Not sure I'd call it irrational, probably just playing it safe. Get something working, then upgrade it.

Part of David's dream is for it to be an easy to program, inexpensive, educational computer. The feature creep had turned it into something way beyond that, and it he wasn't certain they could make the multiplexed buss of the 65816 work at the higher speed. You have to latch the upper address lines in the first part of the buss cycle. That makes you run the parts on the buss faster than the CPU, and you start having to worry about how fast the parts are. Instead of 8 MHz, you are now worrying about parts that might function at 16 MHz, or at least settle times on things like RAM have to be fast enough. At the very least, it may make the machine more expensive than the intended goal.

Doesn't the 9928 do video overlay? One could overlay it's output over the other. Then you are just running more sprites on the 2nd vdp.

The VIP is more like the early single board machines like the KIM 1... but with a really limited video added on. I'd love to spend some time programming the CPU, but the rest of the hardware is so limited, it's hardly worth messing with. It's cool from a historical standpoint though. I think I'd skip the Altair and go with a modern equivalent. There's a work alike machine out of Japan with a Z180 (64180?) that looks pretty cool.

Humblebundle.com has the Endless Space Collection free for a limited time when you subscribe to their newsletter https://www.humblebundle.com/store/endless-space-collection-free-game

Never heard of this one before. No way they should ever just fall out. Are you absolutely certain they are plugged all the way in?

I'm not sure if they were all the same, but mine all had a screw on the top under the label

Have you used this TV with any 8 bit computers before? Some have issues with the frequency of the output. Try a different RF cable. Try reseating the chips in the sockets.

Celest and Inside are free on the Epic Games Launcher

Play Rainbow Six Siege, free this week on UPLAY, EPIC Games launcher, and Steam. If you like it, you can buy the full game at a discount. UPLAY said $8. Details: https://support.ubi.com/en-US/Faqs/000045901 You can also "GRAB ASSASSIN'S CREED: ODYSSEY'S "FIELDS OF ELYSIUM" FOR FREE! (08/26 - 09/01)" on UPLAY https://support.ubi.com/en-US/News/000046890/Grab-Assassin-s-Creed-Odyssey-s-Fields-of-Elysium-for-free-08-26-09-01-ACOD "The Assassin’s Creed Odyssey base game is required to access season pass content, including the Fields of Elysium episode."

I think that "suspicious mod" looks like one from the factory that was on some machines. The RF output on CoCos wasn't that great. I'd look for a new composite board.

'For Honor', for free, for a limited time. https://news.ubisoft.com/en-us/article/354306/Get-For-Honor-Free-on-Uplay-for-a-Limited-Time

The latest EPIC freebies are up https://www.epicgames.com/store/en-US/collection/free-game-collection

The ORIC does support integers, but you have to specify them with the % sign at the end, which takes longer to parse, but at least it supports them. Example: A%=1:DIM I%(size)

Apple II, Commodore VIC20 / C64 / Plus/4 / C128... nope. Maybe the ORIC did, since it also has ELSE, where earlier 6502 versions didn't. The ORIC came out after the Atari version. Maybe some of the Tompson machines (6809) had int, but I'm not sure. It was common on a lot of Z80 versions except really cheap machines. That one's new to me. I don't remember that on the Model I & III. The loop variable X should be changed to something else then.

I'm pretty sure a brought up the fact that everything the MC-10 did was floats. The Atari version may be the only 6502 version that supports INTs, and none of the 68xx versions I'm aware of do. Try changing the code like this: 0 DEFINT I,M,I0,IH,IL,J,P,X,O,T,Q,L,N,S 1 J=0:R1$="":M=J:I0=J:IH=J:O=1:T=2:Q=-1 44 IH=INT(IW/T):I0=I(IL+IH)

Most MS BASICs don't support INTs was my point.

DEFINT requires support for integers.

Speeding up the interpreter's variable lookup code should help speed this up significantly. That is already on my to do list. Just changing the code a bit offers significant improvement. The code below isn't optimal, but it's better without really altering the algorithm. This code, which includes turning off the display for the memory move on the Plus/4, drops the time to a little under 24.5 minutes. The MC-10 with new ROM completes it in 22:36. Even a minor patch to the Plus/4 should make it pass the MC-10. More efficient algorithms make a big difference, but ultimately, MHz matters. Ditching multi-character variable names completely would make this faster. MS BASIC only recognizes the first 2 characters anyway. Improving the order variables are defined in at the top could speed it up, and changing a few more lines of code might help cut a few more minutes off of the time. Using machine language for the insert memory move would probably offer the biggest improvement since it would bypass all the variable lookups and expression evaluation code, but then that's not benchmarking BASIC anymore. It would be interesting to see how much time is spent in that loop though.

Looks like the = assignment drops to the expression evaluator. The best way to fix this, is to identify it tokenization time and give it a different token than testing for =.

As I've said before, MS BASIC doesn't tokenize constants, including line numbers in GOTOs, and I haven't made any optimizations dealing with speeding up GOTO, or GOSUB yet. After seeing this, it looks like a generic memory copy may be used to copy from one float to another. If that's the case, I'll add a special case for that. It would speed up a LOT of things. FWIW, minor changes to the code cuts off over 5 minutes, and a few more changes might drop another 5. The memory move seems slow. I'll have to see what code is being called. I am NOT timing the Apple. I won't sit around that long. The Plus/4 does it in about 35.5 minutes without blanking the screen.