Commander X16 vs. Mega 65

[mrdoornbos 43]

I renamed the Joplin notebook I have for X16 stuff to "The feature creep was too strong to resist".

[rje 303]

10 minutes ago, paulscottrobson said:

Depends. You could probably chuck all the floating point stuff in its entirety ; it's only there really because MS Basic comes from Dartmouth Basic. No-one's going to do their accounts on an X16. Whether 16 or 32 bit integers, it's questionable.

Heresy!

 

Ok, my initial knee-jerk reaction is over, so I can think about that.  Integer BASIC, eh?  Hmmmmm.

And "yes" to structured BASIC, of course.  I was aiming for the lowerbound, but yes, removing line numbers already means "different animal entirely", so...

I'd love to geek out over a structured syntax.  This is probably not the thread for it.  On the other hand, it's probably ok.

Quote

The nice thing about STOS is the bank/task switching design, so you can have multiple programs running at once ; a sprite editor in one block, tile editor in another, music editor in a third, and so on.

Wow.  I barely have a concept for that on an 8-bit system.  Doesn't Acheron do that?  

Quote

Might as well add in REPEAT/WHILE/Block IF/ELSE/ENDIF and named Procedures ; doesn't take up much space, nor do locals.

I was thinking about the "C-Lox" implementation I'd been beating my head against on the X16, and thinking that instead of parentheses in its if statement, I'd rather use a colon (as a shorthand for "then" I guess).  Even though it resembles Python in a superficial way...

if foo < bar:
   do things, please
endif  # or whatever serves to end a block politely


while foo < bar:
  do other things, please
end # endwhile is awfully bulky

 

 

Edited December 21, 2020 by rje

[paulscottrobson 57]

1 hour ago, TomXP411 said:

While I mostly think we've moved on from the need for line numbered BASIC in Computer Science, I don't see a lot of replacements that can fill the shoes of Advanced BASIC as a first language

 

Two things - the immediacy - if you type CIRCLE 100,100,80 you get a Circle. The other thing is the abandonment of the state machine that you get in most of these systems. FSMs are very flexible but complicated to grasp. In a language like BASIC you can have directly acting code rather than a layer.

Most of the downsides of BASIC are down to specific BASICs - GOSUB, line numbers, two character identifiers and so on.

There's no reason why you can't have all of them ; an emulator on a modern PC, one on a Raspi, one in Javascript and a physical machine. The thing I don't like about Maximite is it's not a real computer - it's a BASIC interpreter running on a MCU. So you can't really program it in Assembler.

There is one issue, which is some things are difficult to emulate at speed, the most obvious in X16 is pixel level collisions. Sometimes you have to make some compromises in the design.

[paulscottrobson 57]

2 minutes ago, rje said:

Heresy!

 

Ok, my initial knee-jerk reaction is over, so I can think about that.  Integer BASIC, eh?  Hmmmmm.

And "yes" to structured BASIC, of course.  I was aiming for the lowerbound, but yes, removing line numbers already means "different animal entirely", so...

 

If you're doing multiple platform designs you can keep but not use the line numbers. If you have a proper editor, just hide them, if you are running in a TTY situation they can be quite handy. The thing is you want a language where their sole function is ordering the code. Also makes it much easier to compile it.

[rje 303]

2 hours ago, TomXP411 said:

While I mostly think we've moved on from the need for line numbered BASIC in Computer Science, I don't see a lot of replacements that can fill the shoes of Advanced BASIC as a first language...

Add to that the likelihood that a programming language on the X16 "should" fit in 16K.  In other words, a subset of Algol 68 that (strongly) resembles a structured BASIC.

Paul's suggestion, that line numbers are hidden entities which only maintain program order and aid in debugging, is a good idea.

I've already figured, in a very loosey goosey fashion, that any imperative language stripped down to fit into 16K is going to essentially resemble a BASIC subset of Algol 68.  What I mean is that one could call it "Retro Python" for marketing hype and maybe a tiny bit of syntactic sugar, but it will be just as far away from Python as it will be from C, Perl, Pascal, Swift, Dart, Go...   ah maybe farther, but the error measurements here are large.

* * *

I've been coding shell-like scripts for decades now, and I still appreciate sigils.  Although in the Unix world, the sigils are at the front of the variable, not the back.  I suspect that was done to make parsing easier: a dollar sign plus an alpha equals the start of a variable.

 

Edited December 21, 2020 by rje

[TomXP411 434]

3 hours ago, paulscottrobson said:

Two things - the immediacy - if you type CIRCLE 100,100,80 you get a Circle. The other thing is the abandonment of the state machine that you get in most of these systems. FSMs are very flexible but complicated to grasp. In a language like BASIC you can have directly acting code rather than a layer.

Most of the downsides of BASIC are down to specific BASICs - GOSUB, line numbers, two character identifiers and so on.

There's no reason why you can't have all of them ; an emulator on a modern PC, one on a Raspi, one in Javascript and a physical machine. The thing I don't like about Maximite is it's not a real computer - it's a BASIC interpreter running on a MCU. So you can't really program it in Assembler.

There is one issue, which is some things are difficult to emulate at speed, the most obvious in X16 is pixel level collisions. Sometimes you have to make some compromises in the design.

There's no reason you can't add the ability to load and run machine code binaries on the Maximite, although loading it down with assembly and C++ toolchains kind of ruins its simplicity.

 

[PadreHomer 4]

As a novice the X16 appeals to me because it is kept simple so that I feel I can still learn to understand the inner workings. It’s close to a c64 which I had as a child so it checks that nostalgia box, and it pushes the envelope a bit by having a higher clock speed and some other features that make it superior in specs to a c64 which makes it a new thing. Also keeping it at a lower price point makes it accessible.


Sent from my iPhone using Tapatalk

[Cyber 189]

7 hours ago, paulscottrobson said:

The thing I don't like about Maximite is it's not a real computer - it's a BASIC interpreter running on a MCU. So you can't really program it in Assembler.

Not entirely it's not a real computer. While its BASIC interpreter is written in 32-bit C, you can't call it an emulation, because the real hardware is actually used. So BASIC here is more like a firmware ROM, and while running it uses real CPU and real memory inside MCU.
And while you don't have Assembler, you have PEEK and POKE to interact with memory directly. Pretty good for exploration and education.

[paulscottrobson 57]

8 hours ago, TomXP411 said:

There's no reason you can't add the ability to load and run machine code binaries on the Maximite, although loading it down with assembly and C++ toolchains kind of ruins its simplicity.

 

I was always a big fan of the BBC Basic Assembler. Allowed you to tinker without being a full bore system. I wrote a lot of ARM code that way I'm a big fan of the idea - I've actually got one though I haven't done much with it yet. It fulfils the #1 criteria I think a system designed for learning should have, which is that the built in programming system, whatever it is, should be fast enough to produce 1980s type games without struggling.  Someone wrote a very nice Boulderdash type game in BASIC, but you can see the limitations in the code to make it quick enough.

Edited December 22, 2020 by paulscottrobson
Added stuff

[paulscottrobson 57]

4 hours ago, Cyber said:

Not entirely it's not a real computer. While its BASIC interpreter is written in 32-bit C, you can't call it an emulation, because the real hardware is actually used. So BASIC here is more like a firmware ROM, and while running it uses real CPU and real memory inside MCU.
And while you don't have Assembler, you have PEEK and POKE to interact with memory directly. Pretty good for exploration and education.

Well, in that sense, yes it is, but it doesn't have the accessible layer below. And ARM RISC is way too complex for a beginner.

[hth313 11]

To be honest, for me the main advantage of the Commander X16 over the Mega 65 is the simplicity. It is a standard 6502 (well 65C02) with a simple memory model.

However, I think that I will actually just get a new Commodore 64 over any of these machines as it does everything I want. I would just go and buy an Ultimate-64 if I could get a new keyboard for it, but I can't. Thus, I wait and see if the Mega 65 comes out and if the price is not over the top, then I will probably get one and basically see it as a variant of the Ultimate-64.

The limitations of the C64 is actually a benefit as if I want to do something myself, as I have to work inside the constraints. It is probably just as fun and also avoids feature creep, making it more likely that I actually have time to finish something.

If I wanted something more, then I think I would just do like I did 1987 when I sold my C128D and replaced it with an Amiga. The Vampire Standalone is not that over the top in price and offers a lot more. I prefer that over the Mega 65 when it comes to the extra abilities.
 

[mrdoornbos 43]

4 minutes ago, hth313 said:

To be honest, for me the main advantage of the Commander X16 over the Mega 65 is the simplicity. It is a standard 6502 (well 65C02) with a simple memory model.

However, I think that I will actually just get a new Commodore 64 over any of these machines as it does everything I want. I would just go and buy an Ultimate-64 if I could get a new keyboard for it, but I can't. Thus, I wait and see if the Mega 65 comes out and if the price is not over the top, then I will probably get one and basically see it as a variant of the Ultimate-64.

The limitations of the C64 is actually a benefit as if I want to do something myself, as I have to work inside the constraints. It is probably just as fun and also avoids feature creep, making it more likely that I actually have time to finish something.

If I wanted something more, then I think I would just do like I did 1987 when I sold my C128D and replaced it with an Amiga. The Vampire Standalone is not that over the top in price and offers a lot more. I prefer that over the Mega 65 when it comes to the extra abilities.
 

Yeah, this is interesting to think about. It's a "what is this for". I agree with you here, I've still got years left of C64 discovery left in me and I already own several of them so I'm not sure what I'd do with this.

I WANT to think of something, don't get me wrong. I think there's room for a project like this if the community can find a "why".

[rje 303]

37 minutes ago, mrdoornbos said:

Yeah, this is interesting to think about. It's a "what is this for". I agree with you here, I've still got years left of C64 discovery left in me and I already own several of them so I'm not sure what I'd do with this.

I WANT to think of something, don't get me wrong. I think there's room for a project like this if the community can find a "why".

I donated my 64 to a friend several years ago, and I haven't picked up The64 or similar, though I do use VICE.  So I guess I'm not as attached to it as I used to be.  The C64 has several things about it that I never liked, and some things I didn't know I didn't like until I saw the X16.

1. Only 8 sprites, unless I do the multiplexing thing which feels painful, and I never fully got the hang of.
2. The 1980s TV-friendly 40 column display.  I didn't know it at the time, but I always wanted at least 64, and preferably 80 columns.
3. Easy RAM banking.  Maybe this is easy on the C64, and maybe not -- but it sounds painful.
4. 1MHz.  I know I know, speed is addictive and never satisfies.  But still.

Rather than feeding feature creep, these preferences are more about Ease Of Use. 

 

That said, I think some of the VERA bitfields required to use its sprite engine make those lovely sprites Harder To Use, which bothers me.  I haven't played with the sound generator in VERA yet, so I don't know how it compares with the SID.  I didn't really have complaints about the SID -- especially when Compute! magazine's SuperBASIC came along and packaged many sprite and sound commands into convenience statements in a BASIC wedge.

[hth313 11]

I should add that I appreciate having the computer in a separate box. I never liked the computer in a keyboard design (having owned C64 breadbin and Amiga 500).

The thing with less memory and slower computer is that you have to work with what you have. That can give a lot of satisfaction getting it to work within constraints.

But, yes, you have good points. The 40 column display is annoying and the VERA may be interesting to have. I see myself as mostly using it for remote debugging. If I ever sit down to do things it would be using Forth and in such case I would surely appreciate having 64 or 80 columns.

I wish there was a 6551 serial port included, or least a socket for one, but I suppose it would not handle 8MHz anyway. It would be very useful for remote debugging.

I will definitely follow the Commander X16 and the alternatives to see how it goes, no decisions on my side yet. Well, I already have an Amiga that gathers dust most of the time, so I do not think I will get the Vampire in the near future at least.
 

Edited December 29, 2020 by hth313
Grammar

[CursorKeys 54]

I'm pretty late to this post, but it's very interesting to me.

To me it's all about how easy it is to get started.

 

I would not be on this website as much as I am right now, for two things.

• The 8 Bit guys' cool introduction video to this project.
• The try it now button / integrated with the uploaded software section on this website.
• The community of people, with the forums right here.

 

For me getting the X16, which I definitely will do, is really cool.

But what is cooler, for now, is this website, the online emulator, and the awesome community. 

I could not stay interested long, otherwise.  Especially, if the release date is not fixed, to me the community and the emulator are more or less the X16, until the real thing comes out.

 

For the Mega65, all information, chats, download site, emulator, is more scattered, and you need to put more effort into "getting something to work".

 

And with only so much time to spend, (job, family and so on, it's not anymore when I was a student and could spend weeks and weeks on a single project),  it is simpler to go deep quicker with the X16.  For me the Mega involvement will be there, but is just lagging behind, because of the reasons above.

To me the only drawback on the X16 so far is really sound.  Mega65 has SID, X16 does not. X16 is a bit unclear on what sound we will have in the end product.

But then again, it's not a deal breaker for me.  I like the X16 as it is

In fact I also like the Mega65, I think both are amazing projects, by dedicated individuals.

 

Edited June 27 by CursorKeys

[Starsickle 21]

I've never heard of it, but took some time to check it out.

I'd have to go back to the specifications for my personal desires:

• I want a computer I can regularly use. That's the fun of it.
• I'm fine with a 8-bit CPU. The Mega65 is using a modern FPGA to build the circuit logic of the 6502. Conceivably, it will run faster because everything is programmed into the FPGA.
• Digital outputs. I'm not a collector of old TVs and monitors. That means HDMI, USB, and SD card slots.
• SD card slots with programmatic support for file access.
• Easy to program - memory and optimization can come last after building a product.

The Dire Problem of Nostalgia:

I've been thinking a bit about this - and I would hate to admit this, but it's in my mind when I compare the machines: The compatibility issue with the original C64 or VIC-20 is the ultimate overcommitment, because the truth is that these machines were infants in terms of design, usability, and capability. What both projects have right now is a crisis of identity versus the needs in capability of its users. We simply expect more of our computers. I think that one would either design to make an old machine OR a new machine with the old machine's parts.

In this, I'd favor the X16. I want to see the 6502. I want to see chips (Feel free to use modern RAM). I don't mind programming in some form of BASIC: The problem for me is that I know over 40 years of improvement have gone into computing, computers, and our use of computers. We've already had them in our lives, and so we expect more of them.

I'm fairly sure the Mega65 is facing the same problem, and the proof of that is its extensive documentation, modes, switching, and memory management. A glance at Mega65 BASIC and the underlaying Assembly (I am bad at assembly) would make me probably prefer Mega65 programming at the moment. I keep making comparisons to SmileBASIC in terms of ease of use. (Honestly, if everything on SmileBASIC servers weren't implicitly copyleft, I'd be making BASIC games on the Switch right now.)

The Mega65 looks like a complete computer. Ethernet port, HDMI port, SD card slots. It's only missing USB. Why does it not have a USB port? It's 2021. Everything is USB.

Disk Drives? No. I am not going out to buy floppies in the year two thousand and twenty one. Just no. If I want a retrocomputer that works worse than my phone, I'll become an antique collector.

In all, the Mega65 looks like junk, is probably extremely capable once literally everything is automatically managed or wrapped up, and will probably be a very capable computer....if it adds USB. The X16 currently is trying to reconcile backwards compatibility with modern programming convenience. I have no straight answer to this, but I just want it to succeed and be able to straightforwardly program without arcane trickery. As long as I can keep doing include and execute, the sky's the limit.

Edited July 3 by Starsickle
Include and execute.

[BruceMcF 407]

1 hour ago, Starsickle said:

In this, I'd favor the X16. I want to see the 6502. I want to see chips (Feel free to use modern RAM). I don't mind programming in some form of BASIC: The problem for me is that I know over 40 years of improvement have gone into computing, computers, and our use of computers. We've already had them in our lives, and so we expect more of them.

But it will be interesting to see how much of the ease of use is from solutions we had not arrived at before and how much is just burning cycles we didn't have available to burn before.

[paulscottrobson 57]

2 hours ago, BruceMcF said:

But it will be interesting to see how much of the ease of use is from solutions we had not arrived at before and how much is just burning cycles we didn't have available to burn before.

I’m a believer in the idea that modern coding wastes cycles, memory etc. I started professionally coding on Windows 3.0 and Word 2.0 (?). Odd thing is it didn’t seem to be much slower if at all, and Word did pretty much the same stuff. I think they’d just added the wiggly line spellchecker.

[Kalvan 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.

Edited Friday at 03:37 PM by Kalvan

[rje 303]

 

I think "ease of use" is, almost literally, how much performance you can sacrifice to make things easier on the coder.

- me, just now

 

Quote

I’m a believer in the idea that modern coding wastes cycles, memory etc.

It's true.  But conversely, archaic coding wastes developers' time.  There is a fuzzy middle where the two lines cross; it's fuzzy because people represent different points near that intersection.

I will always be a "beginner" when it comes to hardware and assembly language.  My brain was never there.  I can grok it, but I could never be patient enough to live there.

 

 

*** I think those lines crossed about the time the 16 bit processor came out.  That's why the X16 has "16 bit" performance on graphics and sound.

Theoretically the 16 bit processor *could* enable better Ease of Use, because of what Paul wrote:

Quote

The [Mega65] is fast enough to [...] write proper retro style games without having to write in Assembler, and you can run a fast enough P-Code system. [...] the CX16 doesn't quite have it (by a factor of 2-3) without big chunks of assembler [...] [this] handicaps the beginners. The more the merrier though, why not Robotron in BASIC.

Given (assumption) that the Mega65 makes sprites easy and sound easy, then speed IS an Ease of Use improvement.

But I fear scope creep because it is real.

 

If moving back to the W65C816S is "all it takes", then I think about the redesign requirements and the cost estimates and see if Dave's decision is worth revisiting.

I'll start a new thread on THAT.

 

Edited Friday at 04:57 PM by rje

[paulscottrobson 57]

"Given (assumption) that the Mega65 makes sprites easy and sound easy, then speed IS an Ease of Use improvement. "

AFAIK it's about the same. Most of the sprite API is fairly straightforward. It's the data and ease of use that's the issue. I've a Python script that builds graphics into a single file with autoscaling and so on, RLE encodes it and indexes it along with size/alignment information. Data is unpacked into $A000 RAM. It works well enough.

The other tricky bit is if you want automovement.

[rje 303]

33 minutes ago, paulscottrobson said:

The other tricky bit is if you want automovement.

Automovement sounds fancy, as if one could specify a vector and the system will automagically move the sprite along that vector, until acted upon by the programmer's code.

 

Didn't need that on the C64; don't need it now.  What I do need is a sound API,   because (e.g.) on the C64 I couldn't do decent sound until SuperBASIC made it more accessible than POKEs.  Then I was happy.

The Sprite ABI that Michael Steil wrote is perfectly fine for sprite management.

 

Edited Friday at 10:00 PM by rje