Jump to content

8-bit Battle Royale!


Recommended Posts

Well, if you keep it to 8-bit machines...

The Fujitsu FM 8/7/77 series featured two Motorola 6809s, and the final version (released in 1988) can display its full master palette of 262,144 colors at 320x200 resolution, and 512 colors at 640x400.  While it technically has no hardware sprites, the combination of a dedicated Video CPU, and hardware multiply and divide can be a remarkable equalizer, especially when it comes to object scaling and rotation.

The MSX Turbo-R spec was only released in three models by Panasonic and one by Sanyo, but it featured a Z80-based CPU clocked at 7.16Mhz that executed an instruction every clock cycle, a master palette of 16,384 colors (all of them available at 256x212 resolution), a max resolution of 1024x424 (4 Colors), with 24 Channels of FM Synthesis (Yamaha Y8950, YM2413, and YM2808 or YM2610A), Four Channels of Geometry Synthesis, and one channel off 8 bits of PCM synthesis, with a grand total of 512K of audio buffer.

I'll keep on looking, but we can start with these.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

I am only speaking for myself, and this is not a criticism, just a preference, regarding this series.

I feel like there is too much exposition around the programs in this series. I don't have a concrete suggestion on how to enhance it, but 53 minutes (for this most recent one) to explain the three versions is just a long time to sit through (so I didn't; I jumped a lot closer to the actual runs).

Where you are making code available, people who are really interested in that can go look at it, of course. I think that even cutting the exposition in half would go a long way to make the videos even more watchable (which is not to say they are unwatchable).

This could be just me and maybe everyone else feels differently. Just trying to be helpful, and hopefully not hurtful.

I am enjoying the series though and have watched all three parts so far, just with a faster playback and skipping some of the exposition to get to the actual thing I want to personally see, the run / results.

Link to comment
Share on other sites

My patrons and subscribers are folks who really want to learn about assembly development, and 8-bit homebrew in general. This is what they are coming for, as "mainstream" channels aren't going deep enough for them. I do make some videos at a higher level, but they don't always do as well. So, back to the niche I go!

  • Like 3
Link to comment
Share on other sites

The audience being targeted is not just us old farts who remember all these old details, but the newbies who are just getting into the scene and don't know that TRS-80s say CLS to clear the screen while Apple IIs say HOME and Commodore 64s say PRINT CHR$(147).

Link to comment
Share on other sites

Like I said ... it was just an opinion, and @SlithyMatt has explained it now. Just trying to provide constructive feedback, not trying to denigrate anyone or anything. I've worked in radio and had to do airchecks, reviewing my work to get better. This was just an opportunity to provide an unsolicited aircheck. I'm not trying to be a typical internet troll. 🙂

 

  • Like 1
Link to comment
Share on other sites

10 hours ago, SlithyMatt said:

My patrons and subscribers are folks who really want to learn about assembly development, and 8-bit homebrew in general. This is what they are coming for, as "mainstream" channels aren't going deep enough for them. I do make some videos at a higher level, but they don't always do as well. So, back to the niche I go!

Though now that you have those, a 10-15min round up video that links back to those with time-stamped cards and links but focuses on the Battle Royal itself would be good for sharing on Twitter, Facebook, etc.

  • Like 1
Link to comment
Share on other sites

9 hours ago, BruceMcF said:

Though now that you have those, a 10-15min round up video that links back to those with time-stamped cards and links but focuses on the Battle Royal itself would be good for sharing on Twitter, Facebook, etc.

Good point. Though then you risk fragmenting your video views, and sadly, the way YouTube works, one video with high views is better than catering to multiple audiences. It's the YouTube Kobayashi Maru.

  • Like 1
Link to comment
Share on other sites

8 minutes ago, Scott Robison said:

Good point. Though then you risk fragmenting your video views, and sadly, the way YouTube works, one video with high views is better than catering to multiple audiences. It's the YouTube Kobayashi Maru.

The idea there is to boost the views of the originals by making it easier to pull people in. So it would not be up until the views of the originals taper off.

Edited by BruceMcF
  • Like 3
Link to comment
Share on other sites

Nice update. In playing around with the C=64 BASIC version, I was able to speed it up by approximately 16% by changing the algorithm a little bit. Precomputing some values so they didn't have to be computed every time through the loop or repeated in multiple locations. It means using a little more RAM of course. None of the changes were to crunch it to save time in BASIC interpretation.

Given the advantage to 6502 vs Z80 when it comes to RAM access, I think that would be a good optimization to apply to the assembly language versions (which I've not looked at closely so maybe you are pre-computing).

My repo fork is https://github.com/CasaDeRobison/multi-mandlebrot/ ... c64-basic-tweaks is the branch. A bunch of little incremental changes, one per commit, as I experimented with different things.

  • Like 1
Link to comment
Share on other sites

I purposely kept those value computations in there, as that was part of the original algorithm, and I wanted to make sure all the calculations were happening, even if some were needlessly repetitive, like re-computing the bottom half instead of just mirroring it. I'll take a look and see if I can merge some of it in.

Link to comment
Share on other sites

Just now, SlithyMatt said:

I purposely kept those value computations in there, as that was part of the original algorithm, and I wanted to make sure all the calculations were happening, even if some were needlessly repetitive, like re-computing the bottom half instead of just mirroring it. I'll take a look and see if I can merge some of it in.

Understood. I realize that each version needs to be as similar to the others as possible for the benchmark to be meaningful. I just think that using a bit more RAM for temporary values would show 6502 in a better light since it doesn't have as many registers. Z80 would also save the time of recomputing values, but it takes longer to access memory.

Anyway, just some thoughts in case they provide anything useful. Don't feel obligated to them

Back when I was a TA for a FORTRAN class, we had an assignment we would give students to computer a list of Armstrong numbers. They are not useful, but interesting. If you take a number, split it into its component digits, then raise each digit to the power of the total number of digits in the original number, and compute the sum, and the sum is equal to the original number, it is an Armstrong number. So all 1 digit numbers are Armstrong numbers (1^1 is 1, 2^1 is 2, 3^1 is 3, etc). There are no two digit Armstrong numbers.

Consider 123. 1^3+2^3+3^3 = 1 + 8 + 27 = 36. 36 <> 123, so 123 is not an Armstrong number.

Consider 153. 1^3+5^3+3^3 = 1 + 125 + 27 = 153. 153 = 153, so 153 is an Armstrong number.

There are a ton of ways to compute them. Some algorithms are much faster than others, and lookup tables of values speed up the algorithm a lot when you get into much longer numbers. The key to one solution I created was to avoid multiplication and exponentiation and just use addition and subtraction of values from lookup tables.

Given the relative advantage 6502 has over Z80 in memory access, I thought it might be an interesting video to show that variations of an algorithm can throw the advantage to a different architecture.

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...
2 minutes ago, Scott Robison said:

I'm impressed that the difference was only 6x.

Makes sense when you think about it. The difference between BASIC and 8.8 fixed point in assembly was 7x. The individual BASIC math operations are no more costly in the higher-res plot, but they are in assembly when moving to 16.8 fixed point. So, considering that number representation was 50% larger, it's a pretty small performance penalty going down to only 6x faster than BASIC.

Link to comment
Share on other sites

On 8/25/2021 at 9:52 AM, BruceMcF said:

The idea there is to boost the views of the originals by making it easier to pull people in. So it would not be up until the views of the originals taper off.

A ridiculous brainstorm:  lead your videos with the headlines / bottom lines.  The 15 minute "here's what happens".  Then the 60 minute deep dive.

One video, formatted for two levels of interest?

Edited by rje
  • Like 3
Link to comment
Share on other sites

  • 2 months later...

I appreciate this series on the basis of doing something computationally expensive but visually appealing. There are so many things out there that will do one or the other, or are designed to favor one machine over the other, but this one tries to present a level playing field.

Edited by Scott Robison
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use